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ABSTRACT 


This  thesis  presents  an  effective  methodology  and  tool  set,  that  explicitly 
considers  technological  uncertainty,  to  enable  design,  development,  and  assessment  of 
alternative  system  concept  architectures  for  an  autonomous  unmanned  surface  vessel 
(USV)  in  a  system  of  systems  (SoS)  context. 

Complex  system  designs  often  fail  due  to  poor  communication  of  customer  needs 
and  inadequate  understanding  of  the  overall  problem.  This  frequently  results  in  the 
design  team  missing  the  mark  in  transforming  requirements  into  a  successful  conceptual 
design.  Effective  system  design  requires  a  defined,  flexible,  and  structured  context 
within  which  new  technological  ideas  can  be  judged.  Alternative  physical  architectures 
are  then  modeled,  simulated,  and  compared  to  find  the  “best”  solution  for  further 
examination. 

This  thesis  uses  model-based  systems  engineering  (MBSE)  principles  to  develop  a 
multi-criteria  decision  making  (MCDM)  model  that  allows  designers  to  perform  a 
solution  neutral  investigation  of  possible  alternative  physical  architecture  concepts.  This 
ensures  a  consistent  quantitative  evaluation  of  warfighting  capability,  suitability, 
effectiveness,  technology  maturation,  and  risk  before  and  during  a  program  execution. 
This  effort  is  in  support  of  an  extended  program  to  design  a  system  of  unmanned  systems 
intended  to  provide  the  DoD  with  a  coordinated,  multi-domain,  multi-mission, 
autonomous  security  and  warfighting  asset. 
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EXECUTIVE  SUMMARY 


Like  all  engineering  projects,  this  thesis  began  with  a  question:  How  do 
Department  of  Defense  (DoD)  engineers  efficiently  and  effectively  design  an 
autonomous  surface  vessel  in  support  of  an  overarching  Office  of  Naval  Research  (ONR) 
Unmanned  Vehicle  (UV)  system  of  systems  (SoS)? 

Traditional  DoD  engineering  practices  include  a  threat-based  or  technology- 
driven  design  process,  focusing  on  the  system  components  the  designers  feel  will 
effectively  counter  an  adversary’s  current  and  future  capabilities.  This  bottom-up 
approach  to  system  design  typically  misses  the  mark  in  meeting  stakeholder  capability 
needs  and  fails  to  effectively  perform  the  intended  mission.  The  process  typically  results 
in  the  designer  following  predetennined  design  concepts  leading  to  an  unfavorable 
solution.  In  addition,  the  approach  almost  always  results  in  allocating  large  amounts  of 
money  and  assets  in  areas  that  are  well  outside  the  feasible  design  region  of  the  project, 
wasting  valuable  resources  better  spent  elsewhere. 

This  thesis  offers  an  alternative  approach  to  this  engineering  problem  based  on  a 
capabilities-driven,  model-based,  SoS  engineering  process.  This  holistic  approach  to 
system  design  keeps  the  design  concepts  and  the  designer  in  the  feasible  region  with 
respect  to  physical,  systematic,  and  capability  constraints.  It  presents  an  effective 
methodology  and  tool  set  to  enable  design,  development,  and  assessment  of  alternative 
system  concept  architectures  for  an  autonomous  unmanned  surface  vessel  (USV)  in  a  SoS 
context. 

Using  model-based  systems  engineering  (MBSE)  principles  and  a  derived  multi¬ 
criteria  decision  making  (MCDM)  model  allow  designers  to  perform  a  solution  neutral 
investigation  of  possible  alternative  physical  architecture  concepts.  This  ensures  a 
consistent  quantitative  evaluation  of  warfighting  capability,  suitability,  effectiveness, 
technology  maturation,  and  risk  before  and  during  a  program  execution.  This  effort  is  in 


xix 


support  of  an  extended  program  to  design  a  system  of  unmanned  systems  intended  to 
provide  the  DoD  with  a  coordinated,  multi-domain,  multi-mission,  autonomous  security 
and  warfighting  asset. 
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I.  INTRODUCTION 


A.  OVERVIEW 

This  thesis  presents  an  effective  methodology  and  tool  set  to  enable  design, 
development,  and  assessment  of  alternative  system  concept  architectures  for  an 
autonomous  unmanned  surface  vessel  (USV)  in  a  SoS  context.  The  methodology 
provides  a  consistent  quantitative  evaluation  of  warfighting  capability  suitability, 
effectiveness,  technology  maturation,  and  risk  before  and  during  a  program  execution. 
This  effort  is  in  support  of  an  extended  program  to  design  a  system  of  unmanned  systems 
intended  to  provide  the  DoD  with  a  coordinated,  multi-domain,  multi-mission 
autonomous  security  and  warfighting  asset. 

The  methodology  is  capabilities-driven,  based  on  thorough  generation  and  review 
of  mission-based  ability  to  deliver  a  set  of  desired  effects.  The  MBSE  method  allows  for 
solution  neutral  investigation  of  possible  alternative  physical  architecture  concepts  to 
meet  overall  SoS  needs  based  on  a  traceable  path  to  the  capabilities  desired  as 
documented  by  the  stakeholders.  The  method  developed  provides  the  best  way  to 
compare  alternative  architectures  and  assess  technological  maturity  of  critical  subsystems 
in  meeting  stakeholder  capability  needs. 

The  architecture  structure  is  created,  defined,  edited,  and  configuration  controlled 
and  managed  using  Vitech  CORE.  Linkages  to  engineering  feasibility  analysis  are 
accomplished  using  Microsoft  Excel,  though  other  domain  specific  science,  engineering, 
and  analysis  software  tools  could  also  be  used.  Design  space  creation,  exploration,  and 
trade-off  is  accomplished  using  Microsoft  Excel  and  Statistical  Analysis  Software  (SAS) 
Institute  JMP.  Technology  assessments  and  associated  uncertainty  analyses  are 
accomplished  using  SAS  Institute  JMP. 

Unmanned  vehicle  (UxV)  systems  are  particularly  susceptible  to  missing  the  mark 
in  meeting  stakeholder  needs,  especially  due  to  advanced  concepts,  inclusion  of  uncertain 
technology,  the  need  to  fuse  diverse  elements,  multifaceted  integration  issues,  and  the 
manifestation  of  emergent  properties.  SoS  are  described  as  (Boardman  and  Sauser  2008) 
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...  a  large-scale,  complex  system,  involving  a  combination  of  components 
which  are  systems  themselves,  achieving  a  unique  end-state  by  providing 
synergistic  capability  from  its  component  systems,  and  exhibiting  a 
majority  of  the  following  characteristics:  operational  and  managerial 
independence,  geographic  distribution,  emergent  behavior,  evolutionary 
development,  self-organization,  and  adaptation. 

Designing  a  SoS  requires  an  architecture  development  method  that  implements 
executable  architectures  that  can  be  used  to  model  and  simulate  behaviors  during  the 
design  process. 

System  architecture  development  is  based  on  systems  engineering  principles  and 
involves  expanding  the  areas  of  identifying  a  capability  gap  or  need,  defining  and 
refining  architectural  and  engineering  system  requirements,  analyzing  system  functions, 
allocating  system  functions  to  physical  components,  and  the  application  of  executable 
models.  Building  the  UV  Sentry  system  of  systems  architecture  requires  a  thorough 
MBSE  method  to  ensure  success  in  meeting  stakeholder  capability  needs  and 
transforming  them  into  an  effective  SoS  design. 

The  first  three  chapters  of  this  thesis  build  a  solid  knowledge  base  of  the  concepts 
and  techniques  behind  this  innovative  method.  Chapter  I  provides  a  necessary  overview 
of  the  engineering  and  architecture  development  terms,  processes,  and  concepts  involved 
with  the  design  approach.  Chapter  II  provides  a  description  of  the  UV  Sentry  system  as  a 
whole  and  the  unmanned  surface  vehicles  aspects  of  the  system  of  systems.  Chapter  III 
describes  the  elements  and  techniques  used  in  building  the  system  architecture  and 
model-based  design  tools.  The  final  two  chapters  describe  how  to  build  and  use  the 
MCDM  model.  Chapter  IV  presents  the  architecture  development  and  analysis  method 
for  the  UV  Sentry  unmanned  surface  vessel  using  the  tools  and  techniques  described  in 
the  first  three  chapters.  Chapter  V  provides  a  summary,  conclusions,  and 
recommendations  for  follow-on  work. 

This  thesis  provides  UV  sentry  designers  with  the  appropriate  tools  and  processes 
to  effectively  focus  their  research  and  acquisition  efforts.  This  focus  will  prevent  the 
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unnecessary  disbursement  of  resources  into  non-critical  or  unfeasible  areas.  This  will 
permit  system  designers  to  focus  efforts  in  areas  where  they  are  needed  and  will  have  a 
positive  effect  on  the  overall  design. 


B.  BACKGROUND 

Unmanned  systems  have  increasingly  become  an  integral  element  of  a  wide  range 
of  modern  military  operations  over  the  past  decade.  Unmanned  systems  performed  vital 
roles  on  the  ground,  in  the  water,  and  in  the  skies  during  military  operations  in  Iraq  and 
Afghanistan.  The  DoD  anticipates  these  systems  will  play  an  even  larger  role  in  future 
military  operations.  The  Secretary  of  Defense’s  Unmanned  Systems  Integrated  Roadmap 
FY  2009-2034  highlights  this  with: 

In  today’s  military,  unmanned  systems  are  highly  desired  by  combatant 
commanders  (COCOMs)  for  their  versatility  and  persistence.  By 
performing  tasks  such  as  surveillance;  signals  intelligence  (SIGINT); 
precision  target  designation;  mine  detection;  and  chemical,  biological, 
radiological,  nuclear  (CBRN)  reconnaissance,  unmanned  systems  have 
made  key  contributions  to  the  Global  War  on  Terror  (GWOT).  As  of 
October  2008,  coalition  unmanned  aircraft  systems  (UAS)  (exclusive  of 
hand-launched  systems)  have  flown  almost  500,000  flight  hours  in  support 
of  Operations  Enduring  Freedom  and  Iraqi  Freedom,  unmanned  ground 
vehicles  (UGVs)  have  conducted  over  30,000  missions,  detecting  and/or 
neutralizing  over  15,000  improvised  explosive  devices  (IEDs),  and 
unmanned  maritime  systems  (UMSs)  have  provided  security  to  ports.” 

The  report  continues:  “In  response  to  the  Warfighter  demand,  the 
Department  has  continued  to  invest  aggressively  in  developing  unmanned 
systems  and  technologies.  That  investment  has  seen  unmanned  systems 
transfonned  from  being  primarily  remote  operated,  single-mission 
platforms  into  increasingly  autonomous,  multi-mission  systems  (OSD 
2009). 

The  vulnerability  of  personnel  and  high  value  assets  coupled  with  the  high  cost  of 
manned  platforms  fuels  the  drive  for  the  UV  Sentry  SoS.  The  asymmetric  nature  of  the 
threats  and  the  vast  coverage  areas  intensify  the  need  to  have  a  coordinated  network  of 
unmanned  vessels  to  accomplish  the  dirty,  dull,  and  dangerous  tasks  that  are  now 
performed  with  manned  assets.  The  UV  Sentry  vision  involves  a  versatile  fusion  of 
unmanned  surface,  subsurface,  and  airborne  vehicles,  hereafter  generically  referred  to  as 
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(UxV),  accomplishing  a  broad  set  of  capabilities  providing  persistent  effective  defense  of 
naval  and  maritime  assets  using  manned  and  unmanned  systems.  The  system  will  provide 
information,  surveillance,  and  reconnaissance  (ISR)  to  improve  situational  awareness 
around  a  high-value  asset  (or  group  of  assets).  This  SoS  will  take  action  at  sufficient 
distances  to  neutralize  or  deter  detected  threats,  autonomously  operating  and  sharing 
information  between  system  elements. 

The  DoD  vision  of  future  operations  calls  for  vastly  improved  autonomous 
vehicles  and  greater  synergy  between  air,  ground,  and  maritime  assets.  The  multitude  of 
missions,  domains,  and  environments  coupled  with  the  asymmetrical  nature  of  the  threats 
adds  an  unprecedented  level  of  complexity  facilitating  the  need  for  a  SoS  engineering 
approach  to  the  problem.  The  current  scope  of  the  majority  of  unmanned  vehicle 
programs  is  bound  within  a  limited  mission  in  a  single  domain.  The  UV  Sentry  initiative 
seeks  to  expand  this  scope  to  cover  a  multitude  of  security  related  missions  in  three 
domains  (air,  surface,  and  sub-surface).  Although  the  technology  maturation  for  a  fully 
coordinated,  multi-domain,  multi-mission,  fleet  of  autonomous  vehicles  is  a  work  in 
progress,  a  clear  and  coordinated  plan  is  required  to  develop  a  future  unmanned  system  of 
systems.  The  UV  Sentry  program  is  committed  to  providing  a  coordinated  effort  in 
transforming  disjointed,  stand-alone,  unmanned  vehicle  initiatives  into  a  collaborative 
design  and  acquisition  approach.  This  approach  is  intended  to  set  a  solid  foundation  for 
future  UV  research,  development,  and  acquisition.  Without  this  integrated  approach  to 
force  application  and  mission  accomplishment,  the  project  will  most  likely  lead  to  an 
ineffective  and  disordered  design. 

C.  OBJECTIVES 

The  overall  objective  of  this  thesis  is  to  set  the  foundation  for  the  development  of 
a  system  of  systems  architecture  development  and  engineering  design  process  that  for  the 
development  of  the  future  U.S.  DoD  UV  Sentry  SoS. 
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This  Thesis: 

•  Provides  a  synopsis  of  the  fundamental  design  concepts  used. 

•  Explains  the  scope  and  methodology  of  the  project. 

•  Provides  an  overview  of  unmanned  systems,  the  UV  Sentry  initiative,  and 
autonomous  surface  craft  missions,  classifications,  and  design  concerns. 

•  Provides  an  overview  of  the  design  tools  and  techniques  used  in  this 
project. 

•  Describes  how  to  build  the  model. 

•  Describes  a  real-world  example  of  the  process  using  actual  ship  synthesis 
information. 

•  Briefly  covers  how  statistical  methods  can  be  used  to  study  the  impact  of 
stochastic  inputs  and  uncertainty  in  conceptual  design. 

•  Provides  a  summary,  conclusions,  and  recommendations  based  on  this 
study’s  findings. 

D.  CONTEXT 

The  UV  Sentry  program  is  implementing  the  development  process  shown  in 
Figure  1.  This  section  provides  a  synopsis  of  the  fundamental  design  concepts  used  in 
this  process,  and  applied  to  a  specific  methodology  is  used  to  accomplish  a  MBSE  trade 
study  analysis  for  the  UV  Sentry  program. 
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Figure  1.  UV  Sentry  Architecture  Synthesis.  (From:  Whitcomb  et  al.  2008) 


1.  Capabilities-Based  Planning  (CBP) 

CBP  is  a  systematic  force  development  approach  that  aims  to  develop  the  most 
appropriate  options  to  meet  priorities  such  as  strategic  objectives,  cost  and  risk 
minimization,  and  constraint  compliance  (TTCP  2007).  This  method  involves  a 
functional  analysis  of  operationally  required  capabilities  based  on  the  tasks  required  to 
perform  the  respective  mission(s).  Once  the  capabilities  are  defined,  the  most  cost 
effective  and  efficient  options  that  satisfy  the  requirements  are  sought  (TTCP  2007). 
Figure  1  shows  the  capabilities-based  development  method  embedded  in  the  SE  process. 
The  Capability  Pull  loop  ensures  capability  needs  are  iteratively  reviewed,  analyzed,  and 
revised  throughout  the  SE  process. 

This  development  process  marks  a  transformation  in  DoD’s  approach  to  system 
requirements  definition  and  defense  planning  from  a  from  a  “threat-based”  to  a 
“capabilities-based”  model.  This  process  focuses  on  identifying  the  capabilities  required 
to  solve  a  problem  and  delivering  those  capabilities  to  the  system.  CBP  attempts  to 
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eradicate  traditional  stovepipes,  making  the  planning  process  more  lucid,  rational,  and 
responsive  to  uncertainty,  economic  constraints,  and  risk.  The  CBP  process  focuses  on 
overarching  goals  and  end-states  supporting  analysis,  facilitating  risk  management,  and 
encouraging  innovation.  CBP  forces  system  designers  to  ask  what  do  we  need  to  do 
rather  than  what  equipment  are  we  replacing  (TTCP  2007).  CBP  uses  scenarios  to 
provide  the  context  within  which  the  system  will  operate.  This  context  is  then  used  to 
determine  what  capabilities  are  required  for  the  system  to  meet  its  stated  needs  and  how 
to  measure  its  level  of  capacity.  Capabilities,  often  referred  to  as  operational  scenarios, 
consist  of  a  sequence  of  operational  activities  needed  to  respond  to  or  to  provide  an 
external  stimulus  (Whitcomb  et  al.  2008).  Anticipated  operational  scenarios  are 
developed  in  support  of  a  higher-order  concept  of  operations  (CONOPS)  that  describes 
the  anticipated  strategic,  operational,  and  tactical  levels  of  system  employment.  Valid  and 
well-defined  CONOPS  are  essential  inputs  to  a  successful  capabilities-based 
planning/design  process.  The  CONOPS,  and  associated  operational  scenarios,  drive  the 
conceptual  design  process  and  provides  a  means  for  developing  goals  against  which 
capabilities  are  assessed  (TTCP  2007). 

The  capabilities-based  approach  is  realized  in  the  DoD  through  the  Joint 
Capabilities  Integration  Development  System  (JCIDS).  JCIDS  is  the  DoD’s  principal 
decision-making  process  for  transfonning  the  military  in  support  of  future  strategic  goals. 
JCIDS  uses  a  collaborative  process,  utilizing  joint  concepts  and  integrated  architectures, 
to  identify  capability  gaps  and  approaches  to  bridge  them  (CJCS  2009).  A  capability  need 
is  a  required  function  that  a  system  must  possess  within  specified  conditions  and  to 
essential  performance  levels.  A  capability  gap  is  the  inability  to  achieve  a  desired  effect 
under  specified  conditions  and  standards  through  combinations  of  resources  and 
techniques  to  perform  a  set  of  tasks  (CJCS  2009).  A  Capabilities-Based  Assessment 
(CBA)  is  conducted,  in  accordance  with  JCIDS,  to  identify  capability  needs,  gaps, 
excesses,  and  approaches  to  provide  needed  capabilities  within  a  specified  functional  or 
operational  area  (CJCS  2009).  Once  the  CBA  is  complete  and  the  required  capabilities 
are  identified,  the  JCIDS  process  works  to  transfonn  capabilities  into  solutions. 
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Implementation  of  this  capability-based  development  process  is  the  front-end  to 
the  system  acquisition  and  development  process,  which  must  keep  the  process  focused  on 
the  problem  space  versus  the  solution  space  (Whitcomb  et  al.  2008).  The  outcome  is  the 
system  architecture,  which  defines  system  functions,  elements,  and  relationships.  The 
architecture  is  the  embodiment  of  the  system  and  should  be  understood  and  agreed  upon 
by  all  stakeholders  and  validated  to  meet  all  established  capability  needs. 

2.  Systems  Engineering  Process  (SEP) 

The  DoD  defines  systems  engineering  as: 

Systems  engineering  is  an  interdisciplinary  approach  encompassing  the 
entire  technical  effort  to  evolve  and  verify  an  integrated  and  total  life  cycle 
balanced  set  of  system,  people,  and  process  solutions  that  satisfy  customer 
needs.  Systems  engineering  is  the  integrating  mechanism  across  the 
technical  efforts  related  to  the  development,  manufacturing,  verification, 
deployment,  operations,  support,  disposal  of,  and  user  training  for  systems 
and  their  life  cycle  processes.  Systems  engineering  develops  technical 
information  to  support  the  program  management  decision-making  process 
(OSD  2002). 

Systems  engineering  is  typically  described  as  having  two  domains:  the  technical 
knowledge  domain  in  which  the  systems  engineer  operates;  and  the  systems  engineering 
management  domain  where  the  project  management  occurs  (OSD  2002). 

The  Systems  Engineering  Process  (SEP),  displayed  in  Figure  2,  is  a 
comprehensive,  iterative  and  recursive  problem  solving  process,  for  transforming  needs 
and  requirements  into  a  set  of  system  product  and  process  descriptions.  The  process  is 
applied  sequentially,  one  level  at  a  time,  adding  additional  detail  and  definition  with  each 
level  of  development  (OSD  2002).  This  process  typically  begins  by  identifying  the 
problem  and  associated  stakeholders.  The  problem  is  then  properly  defined  and  refined  to 
ensure  it  properly  describes  the  customer’s  need(s).  Process  inputs  include  customer 
needs/requirements,  technology  base,  and  other  requirements  the  system  must  meet. 

The  first  step  of  the  process  is  the  Requirements  Analysis  phase.  Here  system 

missions  and  environments  are  analyzed,  functional  requirements  identified,  and  design 

constraints  defined.  This  step  develops  a  comprehensive  and  logical  set  of  performance 
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requirements  that  detail  what,  where,  and  how  well  the  system  must  perform.  This  step  is 
particularly  important  as  an  ill-defined  set  of  requirements  will  typically  not  be  met. 

The  next  part  of  the  SE  process  is  the  functional  analysis  phase.  Here  functions 
are  decomposed,  requirements  are  linked  to  various  level  functions,  interfaces  are 
defined,  and  the  functional  architecture  is  defined  and  refined.  The  functional  architecture 
is  the  description  of  the  product  in  terms  of  what  it  does.  This  architecture  is  illustrated 
with  a  functional  hierarchy  diagram  that  displays  the  structure  of  higher-level  functions 
and  their  respective  derivation  to  lower-level  functions.  This  hierarchy  provides  decision 
makers  with  a  clear  vision  of  actual  system  functions  and  how  the  functions  are 
associated  with  one  another. 


system  elements  are  defined;  preferred  process  and  product  solutions  are  selected;  and 
internal  and  external  physical  interfaces  are  defined.  In  general,  design  synthesis  is  the 
process  of  defining  the  physical  architecture  of  the  system  in  tenns  of  its  physical 
elements  with  each  physical  element  meeting  at  least  one  functional  requirement.  “The 
physical  architecture  is  the  basic  structure  for  generating  the  specifications  and  baselines” 
(OSD  2002).  This  phase  may  also  involve  the  use  of  development  tools  such  as:  trade-off 
studies;  risk  analysis  and  management;  and  interface  management. 

Each  phase  of  the  process  is  not  complete  after  its  first  incidence.  The  processes 
include  recursive  loops  for  an  iterative  development  process.  The  Requirements  loop 
provides  feedback  from  the  Functional  Analysis  section  to  the  Requirements  Analysis 
section.  This  provides  the  means  of  mapping  requirements  to  functions  and  back  to  make 
certain  all  functions  are  linked  to  a  requirement.  Any  function  not  linked  to  a  requirement 
is  wasted  effort;  any  requirement  not  linked  to  a  function  will  never  be  met.  The  Design 
loop  links  the  Synthesis  and  Functional  Analysis  phases  providing  a  cyclic  process  for 
mapping  functional  architecture  to  physical  architecture.  This  process  maintains 
continuity  in  the  systems  architecture  model,  ensuring  all  functions  have  physical 
elements  to  perfonn  them.  “The  design  loop  permits  reconsideration  of  how  the  system 
will  perform  its  mission,  and  this  helps  optimize  the  synthesized  design”  (OSD  2002).  In 
addition  to  the  Design  loop,  the  Synthesis  phase  involves  a  Verification  feedback  element 
to  ensure  all  the  requirements  are  met  by  the  physical  architecture.  The  verification 
process  is  a  formal  testing  and  evaluation  method  to  ensure  the  proposed  solution  meets 
all  of  the  requirements. 

The  Systems  Analysis  and  Control  process  provides  the  control  mechanism  for 
the  iterative  SE  process.  This  process  step  provides  general  developmental  oversight  and 
coordination  as  alternative  system  approaches  are  analyzed  in  each  phase  of  the  systems 
engineering  process.  This  oversight  is  essential  in  balancing  all  aspects  of  the  SE  process 
including  trade-off  studies  and  risk  management.  In  addition,  the  process  assures 
alternative  system  decisions  are  made  only  after  their  system  effectiveness  impact  is 
evaluated  and  that  product  and  process  design  requirements  are  directly  traceable  to 
functional  and  performance  requirements  (OSD  2002).  The  primary  output  of  the  SE 
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process  is  the  system  architecture.  The  system  architecture  includes  the  physical  and 
functional  hierarchies  and  the  system  specifications.  The  systems  engineering  process 
output  provides  the  necessary  information  to  illuminate  the  conceptual  system  design  and 
describes  system  characteristics  such  as  cost,  performance,  and  risk. 

3.  System  of  Systems  Engineering 

SoS  describes  an  integrated  arrangement  of  interoperable  systems  acting  as  a 
single  functional  entity  to  achieve  a  mission  capability.  A  SoS  is  defined  by  Boardman 
and  Suaser  (2008)  as: 

...a  large-scale,  complex  system,  involving  a  combination  of  components 
which  are  systems  themselves,  achieving  a  unique  end-state  by  providing 
synergistic  capability  from  its  component  systems,  and  exhibiting  a 
majority  of  the  following  characteristics:  operational  and  managerial 
independence,  geographic  distribution,  emergent  behavior,  evolutionary 
development,  self-organization,  and  adaptation  (Boardman  and  Sauser 
2008). 

Typical  characteristics  of  a  system  of  systems  include  a  high  degree  of 
collaboration  and  coordination,  flexible  addition  or  removal  of  component  systems,  and  a 
net-centric  architecture  (ASN  RDA  2006).  The  SoS  possesses  capabilities  not  possessed 
by  the  simple  sum  of  the  constituent  capabilities  operating  separately.  Individual  SoS 
elements  are  typically  able  to  operate  independently  and  may  be  separately  managed. 
Management,  organization,  integration,  and  interoperability  between  the  constituent 
systems  are  often  major  challenges  for  SoS  development  and  implementation. 

A  system  of  systems  is  often  confused  with  a  family  of  systems.  In  a  system  of 
systems,  subsystems  are  related  or  connected  to  provide  a  given  capability.  The  loss  of 
any  part  of  the  system  will  degrade  the  perfonnance  or  capabilities  of  the  whole.  In  a 
family  of  systems,  subsystems  provide  similar  capabilities  through  different  approaches 
to  achieve  similar  or  complementary  effects  (CJCS  2009).  Five  principal  characteristics 
that  distinguish  systems  of  systems  from  monolithic  systems  are:  a  SoS  is  composed  of 
systems  which  are  independent  and  useful  in  their  own  right;  managerial  independence  of 
the  systems;  large  geographic  distribution;  evolutionary  development;  and  emergent 
behavior  (Sage  1992). 


11 


SoS  engineering  is  an  emerging  interdisciplinary  approach  to  transform 
capabilities  into  SoS  solutions.  The  architecture  development  of  an  SoS  starts  with  the 
transformation  of  an  operational  capability  need  into  a  set  of  requirements,  which  are 
used  to  guide  the  development  of  functional  and  physical  architectures  through  design 
(Whitcomb  et  al.  2008). 

4.  System  Architecture 

Systems  Architecture  is  “the  fundamental  organization  of  a  system,  embodied  in 
its  components,  their  relationships  to  each  other,  and  to  the  environment,  and  the 
principles  governing  its  design  and  evolution”  (IEEE  2000).  Systems  Architecting  is  the 
process  used  to  develop  and  revise  the  system  architecture.  Systems  architecture 
development,  like  the  SEP,  is  an  iterative  process  involving  participative  discovery  of 
multiple  stakeholders  to  achieve  an  end  state.  In  systems  architecture  development, 
however,  the  end  state  is  a  well-defined,  clear,  all-inclusive,  agreed-upon,  systems 
architecture  that  meets  all  capability  requirements.  Systems  architects  must  work  to 
reduce  ambiguity,  minimize  complexity,  and  focus  creativity,  to  transform  the  capability 
need  from  the  abstract  to  the  concrete  through  a  series  of  ever-evolving  models  of 
continually  improved  fidelity  (Southworth  2008). 

Systems  architecture  development  and  systems  engineering  are  both  essential 
components  of  the  overall  systems  engineering  process,  both  presenting  complementary 
approaches  to  the  development  of  unprecedented  (or  as-yet  fully  conceived)  SoS 
(Whitcomb  et  al.  2008).  Architecting  focuses  on  the  qualitative  aspects  of  the  system  and 
typically  deals  with  undefined  situations  with  immeasurable  quantities.  Engineering 
primarily  deals  with  physical  and  scientific  situations  with  measurable  quantities  and 
concepts  (Maier  and  Rechtin  2002).  DoD  architecture  development  is  directed  by  the 
JCIDS  process  and  should  start  early  in  the  systems  engineering  process  and  be 
introduced  in  the  earliest  part  of  the  acquisition  process.  System  designers  must  pay 
particular  attention  not  to  fall  into  the  trap  of  trying  to  describe  the  total  system  to  the 
individual  component  level  before  bounding  the  requirements  and  properly  developing 
the  system  architecture.  This  mistake  has  the  system  designer  focusing  on  components 
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rather  than  capabilities,  resulting  in  an  ill-formed  architecture.  The  systems  architecture 
development  approach  focuses  on  architecture  development  from  capability  needs.  The 
ultimate  goal  of  systems  architecture  development  is  to  provide  a  well-defined  system  in 
the  application  domain  and  system  that  meets  desired  capabilities  developed  in  the 
solution  domain  (Southworth  2008). 

The  relationship  of  the  system  and  the  architecture  are  shown  in  Figure  3  (IEEE 
2000).  A  system  fulfills  a  mission  and  inhabits  and  influences  an  environment.  A  system 
also  has  stakeholders,  who  have  concerns  that  must  be  met  through  the  use  of  the  system. 
A  system  has  an  architecture,  which  is  described  by  a  description  that  provides  rationale, 
which  is  used  by  the  stakeholders  to  ensure  their  concerns  are  addressed.  The  description 
consists  of  views  that  conform  to  the  stakeholder’s  viewpoint.  A  model  is  used  to 
represent  the  system  structure,  and  allow  for  reasoning  about  that  structure.  Multiple 
architectural  “views”  are  needed  to  allow  stakeholders  to  communicate  with  the 
architects  and  other  stakeholders  in  their  own  language  to  ensure  their  concerns  are 
addressed.  All  views  are  derived  from  a  single  system  structure,  the  architecture  model, 
with  each  view  acting  as  a  lens  projecting  an  image  in  the  stakeholder’s  own  native 
language  as  defined  by  their  own  viewpoint.  Architecture,  then,  exists  for  the  purpose  of 
achieving  a  well-defined  system  in  all  domains,  such  that  the  eventual  system  developed 
will  meet  operator’s  desired  effectiveness  An  architecture  model  is  the  fundamental  basis 
for  engineering  a  system  since  it  is  the  foundation  upon  which  the  entire  development 
depends  (Whitcomb  et  al.  2008). 
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Mission 


fulfills  1..* 


Figure  3.  IEEE  1471  Conceptual  Framework.  (From:  IEEE  2000) 

Complex  systems  present  enonnous  amounts  of  elements  and  interconnections  in 
the  architecture  model.  This  sheer  amount  of  data,  coupled  with  the  need  to  manipulate, 
change,  and  display  architecture  information,  facilitates  the  need  for  a  better  means  to 
communicate  and  influence  architectural  relationships.  Architecture  frameworks  are  tools 
for  coping  with  system  complexity  by  structuring  data  into  different  views  with  common 
communication  language  providing  consistency  and  traceability  to  system  characteristics 
descriptions.  The  architecture  is  defined  through  a  series  of  views,  each  depicting  the 
architecture  in  a  perspective  that  addresses  a  respective  stakeholder’s  needs  (Whitcomb  et 
al.  2008).  “A  view  is  a  projection  of  the  enterprise  architecture  model  that  is  meaningful 
to  one  or  more  system  stakeholders”  (DoD  2007).  Architecture  frameworks  aid  decision 
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makers  in  making  design  choices  by  providing  clear,  comprehensive,  functional  system 
descriptions  understood  by  all  of  the  system  stakeholders.  The  United  States  military  uses 
the  DoD  Architecture  Framework  (DoDAF)  as  its  standard  systems  architecture 
framework.  The  DoDAF  classifies  and  organizes  the  development  of  complex  systems  to 
aid  in  successful  system  design  and  implementation. 

a.  DoD  Architecture  Framework  (DoDAF) 

The  DoDAF  defines  how  to  organize  enterprise  architectures  for  U.S. 
DoD  applications.  The  DoDAF  is  a  descriptive  methodology  for  capturing  high-level 
system  information  using  four  different  display  formats  or  views.  “All  major  DoD 
weapons  and  information  technology  system  procurements  are  required  to  document  their 
enterprise  architectures  using  the  view  products  prescribed  by  the  DoDAF”  (DoD  2007). 
Figure  4  displays  the  architectural  view  categories  and  their  associated  relationships  for 
DoDAF  version  1.5. 


All-View 

Describes  the  Scope  and  Context  (Vocabulary)  of  the  Architecture 


Operational 

View 


Identifies  What  Needs  to  be 
Accomplished  and  Who  Does  It 


f  /k  / 
//</ 

V*  x° 


Systems  and  Services 
View 

■iiiiiia 


Specific  System  Capabilities 
Required  to  Satisfy  Information 
Exchanges 

Technical  Standards  Criteria 
Governing  Interoperable 
Implementation/Procurement  of 
the  Selected  System  Capabilities 


Technical  Standards 
_ View _ 


Prescribes  Standards  and 
Conventions 


l  I 


Figure  4.  DoDAF  View  Categories.  (From:  DoD  2009) 
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The  four  DoDAF  view  sets  are  (DoD  2009): 


•  All  View  (AV):  Describes  the  scope  and  context  (vocabulary)  of  the 
architecture. 

•  Operational  View  (OV):  Identifies  what  needs  to  be  accomplished  and 
who  does  it. 

•  Systems  and  services  View  (SV):  Relates  systems,  services,  and 
characteristics  to  operational  needs. 

•  Technical  standards  View  (TV):  Prescribes  standards  and  conventions. 

Each  view  is  designed  to  provide  a  specific  aspect  of  the  system 
architecture  allowing  a  stakeholder  to  make  infonned  decisions  and  changes.  The 
DoDAF  uses  a  shared  architecture  repository  to  provide  a  common  language  and 
continuity  to  the  architecture  development  process.  The  DoDAF  views  are  defined  by 
Vitech  within  their  Core  Architecture  Data  Model  (CADM),  which  is  used  to  model  the 
capability  needs  of  the  UV  Sentry  unmanned  surface  vessel.  Figure  5  gives  specific 
examples  of  the  four  views  and  brief  examples  of  what  they  illustrate. 


16 


AV-1 

Overview  and  Summary  Information 

AV-2 

Integrated  Dictionary 

OV-1 

High-Level  Operational  Concept  Graphic 

OV-2 

Operational  Node  Connectivity  Description 

OV-3 

Operational  Information  Exchange  Matrix 

OV-4 

Organizational  Relationships  Chart 

OV-5 

Operational  Activity  Model 

OV-6a 

Operational  Rules  Model 

OV-6b 

Operational  State  Transition  Description 

OV-6c 

Operational  Event-Trace  Description 

OV-7 

Logical  Data  Model 

SV-1 

Systems  Interface  Description 

SV-2 

Systems  Communications  Description 

SV-3 

Systems-Systems  Matrix 

SV-4 

Systems  Functionality  Description 

SV-5 

Operational  Activity  to  Systems  Function 
Traceability  Matrix 

SV-6 

Systems  Data  Exchange  Matrix 

SV-7 

Systems  Performance  Parameters  Matrix 

SV-8 

Systems  Evolution  Description 

SV-9 

Systems  Technology  Forecast 

SV-lOa 

Systems  Rules  Model 

SV-lOb 

Systems  State  Transition  Description 

SV-IOc 

Systems  Event-Trace  Description 

SV-11 

Physical  Schema 

TV-1 

Technical  Standards  Profile 

TV-2 

Technical  Standards  Forecast 

Figure  5.  DoDAF  vl.5  Views  Examples.  (From:  DoD  2007) 


b.  Naval  Architecture  Elements  Reference  Guide  (NAERG) 

The  Naval  Architecture  Elements  Reference  Guide  (NAERG)  and  the 
DODAF  provide  the  standard  for  defining  DoD  system  architectures.  While  the  DoDAF 
aids  in  organizing  the  system  architecture,  the  NAERG  provides  the  standard  terminology 
to  be  used  when  describing  system  architecture  elements.  Using  standard  terminology  in 
system  architectures  enables  the  stakeholders  to  properly  communicate,  track, 
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standardize,  and  refine  DoD  architectures  and  their  elements.  Standardization  of 
architecture  development  terms  and  techniques  minimizes  efforts  in  the  integration  of 
elements  within  a  system,  or  SoS  architecture.  The  NAERG  provides  a  repository  of 
information  critical  to  architecture  framework  development  and  programmatic  and 
acquisition  activities.  The  NAERG  includes  the  Common  Systems  Function  List  (CSFL), 
Common  Operational  Activities  List  (COAL),  Common  Information  Element  List 
(CIEL),  Common  Operational  Node  List  (CONL),  Common  System  Node  List  (CSNL), 
and  Common  System  List  (CSL). 

c.  Universal  Naval  Task  List  (UNTL) 

The  Universal  Naval  Task  List  (UNTL)  is  a  combination  of  the  Navy 
Tactical  Task  List  (NTTL)  and  the  Marine  Corps  Task  List  (MCTL).  It  lists  tasks  that  can 
be  performed  by  naval  forces  and  describes  the  measures  of  performance  that  can  be 
implemented  to  evaluate  individual  task  performance.  The  UNTL  is  used  in  conjunction 
with  DoD’s  Universal  Joint  Task  List  (UJTL)  that  contains  a  hierarchy  of  joint  tasks  in 
support  of  joint  service  missions.  Both  provide  a  common  language  baseline  and 
operational  reference  system  for  commanders,  operators,  and  trainers.  Additionally,  both 
can  be  used  by  system  designers  as  an  excellent  source  of  requirements,  capabilities,  and 
combat  activities  required  to  perform  military  missions.  Joint  Mission  Essential  Tasks 
(JMET)  and  Naval  Mission  Essential  Tasks  (NMET)  are  activities  that  operational 
commanders  deem  critical  to  mission  accomplishment.  Both  are  listed  in  the  Joint 
Mission  Essential  Task  List  (JMETL)  and  Naval  Mission  Essential  Task  List  (NMETL), 
respectively,  and  are  chosen  from  the  UJTL  or  UNTL. 

Although  the  UJTL  and  UNTL  are  intended  to  be  used  by  trainers  and 
operational  commanders,  they  provide  system  designers  and  architects  with  a  valuable 
tool  in  determining  capability  needs  through  exploration  of  required  missions  and  tasks. 
The  lists  are  used  to  determine  mission  requirements  by  exploring  the  operations  that 
military  platfonns  are  expected  to  perfonn.  The  missions  are  then  used  to  determine  the 
sets  of  activities  and  capabilities  required  to  perform  the  missions.  Tracing  operations  to 
the  task  level  provides  designers  with  individual  activities  that  must  be  accomplished  by 
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a  military  entity  to  accomplish  the  assigned  mission.  These  tasks  can  aid  the  system 
architect  in  building  comprehensive  functional  and  physical  architectures.  This  process 
also  provides  designers  with  operationally  relevant  tenninology  and  measures  of 
effectiveness  valuable  to  system  development.  This  allows  system  engineers  and 
architects  to  design  a  military  system  using  warfighter  terminology,  focus,  and  measures. 
Using  warfighter  tenninology  and  mission-derived  capability  needs  allow  system 
designers  to  better  communicate  with  the  DoD  customer  and  to  provide  them  with  a  more 
comprehensive  product. 

5.  Design  Reference  Mission  (DRM) 

The  DRM  is  a  documentation  exercise  used  as  a  tool  to  aid  in  the  systems 
engineering  requirements  definition  process  (Skolnick  and  Wilkins  2000,  208-216).  The 
first  step  in  the  concept  development  process  is  to  fully  define  the  requirements  of  the 
desired  system.  This  step  ensures  the  designer  effectively  defines  the  problem  without  a 
preconceived  notion  of  a  particular  solution.  The  DRM  establishes  the  baseline  for 
subsequent  systems  engineering  activities.  It  establishes  the  groundwork  for  the 
generation  of  requirements,  refining  problem  definition,  development  of  concepts, 
analysis  of  alternatives,  and  test  and  evaluation  (Skolnick  and  Wilkins  2000,  208-216). 
The  concept  is  used  to  establish  a  warfighting  CONOPS  for  a  system  and  to  describe  the 
operational  activities  necessary  to  achieve  desired  system  capabilities. 

Composing  a  DRM  begins  with  understanding  the  warfighter’s  operational 
concept.  This  understanding  is  then  used  to  build  a  simulated  environment  in  which 
system  concept  alternatives  are  expected  to  perform.  The  projected  operational 
environment  (POE)  is  the  environment  in  which  the  system  is  expected  to  operate  and 
provides  the  context  within  which  tasks  will  be  performed  in  support  of  the  mission. 
Once  in  a  mission-executable  environment,  the  capabilities  necessary  to  complete  that 
mission  can  be  exercised.  When  designing  a  reference  mission,  it  is  important  to 
understand  the  environment  surrounding  the  mission  analysis.  A  scenario  includes  a  goal, 
a  deployment  of  systems,  a  physical  environment  in  which  the  mission  takes  place  or  is 
executed,  and  whatever  changes  the  environment  will  undergo  as  the  scenario  progresses. 
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“The  DRM  defines  the  specific  projected  threat  and  operating  environment  baseline  for  a 
given  force  element...”  (Skolnick  and  Wilkins  2000,  208-216). 

Operational  Situations  (OPSITS)  are  unique  instances  of  a  DRM  where  the 
variables  can  change.  They  are  identified  based  on  needs  requirements  and  are  meant  to 
feature  selected  operational  characteristics,  or  combinations  thereof,  in  operationally 
viable  combat  environments.  OPSITS  should  be  specifically  developed  to  stress  selected 
system  design  attributes  and  support  functional  and  performance  tradeoff  analysis 
(Skolnick  and  Wilkins  2000,  208-216).  Educated  assumptions  are  made  about  the 
operational  environment,  required  logistics,  deployment,  and  mission  timeline.  The 
systems  engineer  must  determine  which  OPSITS  are  necessary  and  ensure  they  are 
validated  by  subject  matter  experts  (SMEs). 

E.  SCOPE 

The  overall  UV  Sentry  development  process  in  Figure  1  is  broad  enough  to  cover 
the  entire  system  development.  The  scope  of  this  thesis  is  limited  to  the  model-based 
systems  engineering  and  related  trade  off  assessments  for  a  UV  Sentry  autonomous 
surface  craft  designed  to  serve  in  a  force  protection  mission.  The  methods  and  tools 
provided  present  a  baseline  process  for  developing  the  USV  systems  architecture  and 
model-based  tools  for  concept  exploration  and  tradeoff  analysis.  The  analysis  in  this 
thesis  does  not  reflect  a  finalized  conceptual  design.  The  analysis  gives  a  clear  picture  of 
the  process  in  a  “real  world”  design  application. 

The  primary  focus  of  this  thesis  is  to  provide  a  systems  architecture  and 
conceptual  design  footing  for  the  UV  Sentry  SoS  unmanned  surface  vessel  (USV)  design 
team.  It  is  to  be  used  as  a  guideline  for  system  designers  and  architects  and  employed 
when  constructing  their  system-specific  MBSE  architecture  and  design  methodology. 
This  thesis  offers  a  number  of  tools  and  techniques  for  designers  to  build  a 
comprehensive  conceptual  design  leading  to  a  successful  system  design.  It  focuses  on  the 
conceptual  design  of  a  USV  to  provide  explicit  support  to  the  UV  Sentry  SoS  program 
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but  the  methods,  tools,  and  techniques  described  are  not  limited  to  the  design  of  a  USV. 
The  process  described  herein  can  easily  be  used  in  support  of  any  system  or  process 
design. 

F.  METHODOLOGY 

Model-based  design  uses  mathematical  models  and  visual  aids  to  guide  designers 
and  architects  in  the  development,  design,  and  testing  of  systems.  MBSE  is  particularly 
useful  for  designing  large,  complex,  or  highly  integrated  systems  or  systems  of  systems. 
MBSE  significantly  differs  from  traditional  design  by  using  models  to  simulate  system 
performance  to  appropriately  augment  the  use  of  expensive  and  time-consuming 
prototypes  or  teams  of  engineers  making  multiple  performance  calculations  for  each 
operational  scenario.  This  approach  provides  system  designers  with  fast,  flexible,  and 
efficient  tools  that  can  be  used  throughout  system  development  and  test  and  evaluation. 

The  process  begins  by  identifying  the  system  (or  type  of  system)  to  be 
implemented  and  finding,  or  building,  a  model  to  simulate  the  “real-world”  system 
performance  and  interactions.  Once  the  model  is  determined  to  be  acceptable,  it  can  be 
used  to  analyze  predicted,  dynamic  system  performance  and  synthesized  to  test  system 
requirements,  specifications,  and  potential  shortcomings.  Models  can  be  used  early  in 
system  development  providing  the  means  for  system  designers  and  stakeholders  to 
explore  design  concepts  by  simulating  a  proposed  system  point  design  in  its  expected 
operational  environment.  This  allows  designers  to  test  ideas  without  spending  large 
amounts  of  money  on  prototypes  and  physical  testing.  MBSE  also  builds  a  common 
design  environment  facilitating  effective  communication  between  system  stakeholders. 
Using  models  early  in  the  development  process  allows  designers  to  identify  and  correct 
design  issues  before  they  become  too  costly  to  address. 

Figure  6  illustrates  the  simplified  model  configuration  used  in  the  MBSE  SoS 
development  process.  The  SoS  architecting  model,  ship  synthesis  model,  and  MCDM 
tool  are  each  used  to  build  the  conceptual  design.  The  ship  synthesis  model  predicts  the 
physical  performance  of  the  system.  The  architecture  model  includes  the  framework  and 


21 


organizational  structure  for  the  operational,  functional,  and  physical  models.  The  MCDM 
tool  provides  the  means  for  system  developers  to  explore  conceptual  designs  and  analyze 
design  tradeoffs. 


Figure  6.  MBSE  Method. 


Constructing  the  system  architecture  for  the  UV  Sentry  USV  is  a  cooperative 
process  headed  by  the  system  architect  that  must  include  all  system  and  process 
stakeholders.  The  architect  must  continually  work  with  the  stakeholders  to  iteratively 
define  the  system  structure,  resolve  ambiguity,  reduce  complexity,  and  focus  creativity 
toward  a  problem  solution.  The  architect  must  direct  the  transformation  of  the  system 
from  conception  to  realization  by  using  a  series  of  SE  and  architecture  development  tools 
and  techniques.  Each  step  in  the  process  further  develops  the  architecture  model 
increasing  system  clarity  and  fidelity  with  each  design  iteration.  Architecting  principles, 
model-based  methods,  SE  tools,  and  management  activities  are  used  to  define,  develop, 
integrate,  and  evolve  the  functional  and  physical  models.  The  architecture  model  exists  to 
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develop  a  well-defined  system  that  meets  the  desired  system  effectiveness.  The  system 
architecture  provides  the  means  to  model,  simulate,  engineer,  display,  and  test  concepts. 

Defining  the  architecture  model  structure  starts  with  the  transformation  of 
operational  mission  capability  elements  into  a  set  of  operational  activity  elements.  The 
creation  of  the  architecture  model  (the  fundamental  structure  of  a  system)  is  the  key  step 
in  the  transformation  of  loose  requirements  to  a  well-structured  definition  for  system 
development.  In  the  most  basic  terms,  design  can  be  defined  as  a  process  to  detennine 
form  based  on  function.  Creating  various  concepts  through  a  design  process  allows 
engineers  to  explore  the  solution  space,  applying  creativity  to  the  development  of 
concepts.  The  determination  of  how  well  each  concept  accomplishes  functional 
characteristics,  as  manifested  in  the  physical  form  proposed,  becomes  the  basis  for 
selection  of  the  best  concept  solution.  This  conceptual  design  process  is  a  critical  step  in 
transfonning  capability  needs  to  physical  function.  This  step  allows  system  designers  to 
explore  design  alternatives  and  ultimately  select  the  design  that  best  meets  the  needs  of 
the  stakeholders. 

Building  a  model-based  method  using  the  architecture  products  alone  does  not 
provide  adequate  information  for  a  smooth  transition  from  system  development  to  a  more 
traditional  systems  engineering  process.  An  Element  Relationship  Attribute  (ERA) 
structure  is  a  more  rigorous  method  needed  to  define  the  architecture  model,  and  provide 
a  structure  upon  which  to  make  reasoned  decisions.  The  ERA  based  architecture 
definition  language  handles  the  syntax  and  semantics  needed  for  creation  of  the  base 
architecture  model  and  derived  products.  This  includes  the  ability  to  enact  an  iterative 
process  of  discovery  in  meeting  emerging  capability  needs  as  they  arise. 

Next,  operational  activity  elements  are  related  to  functional,  non-functional 
(constraints)  elements,  requirement  (functional  achievement  metrics)  elements,  and  other 
elements.  This  leads  to  the  eventual  specification  of  component  elements  that  are  used  to 
create  the  finished  product.  This  structure  provides  the  basis  necessary  to  facilitate 
concept  trade-off  studies  of  possible  alternatives  by  explicitly  recording  the 
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interconnections  among  elements.  The  method  allows  stakeholders  to  focus  future 
research  efforts  and  prevent  the  expenditure  of  vast  resources  into  non-critical  or  easily 
countered  areas. 

For  this  thesis,  input  variables  are  treated  as  both  uncertain  and  deterministic  to 
create  models  based  on  probability  of  occurrence.  This  facilitates  more  exploratory  trade¬ 
off  studies  showing  probabilities  of  achieving  outcomes  instead  of  hard  boundaries  for 
trade-off.  The  variables  are  defined  by  distributions  of  possible  outcomes,  rather  than 
these  fixed  points,  since  there  is  uncertainty  associated  with  their  achievement,  either  due 
to  technology  limits  or  perhaps  funding  levels  need  to  get  them  to  the  limits  desired  in  the 
time  frame  desired.  This  can  provide  valuable  information  for  technology  planning  and 
maturation  expectations  in  the  technology  development  phases  of  product  acquisition. 
This  method  also  allows  stakeholders  to  tailor  the  model  as  the  program  evolves  to 
account  for  things  such  as  technology  maturation,  cost  growth,  risk  assumption,  or 
requirements  creep.  Specifically,  this  will  be  used  to  detennine  where  to  focus 
technology  investments,  and  what  technology  development  goal  is  required  to  achieve  the 
desired  outcome. 

The  systems  engineering  and  architecture  development  model  was  implemented 
using  the  Vitech  CORE  systems  engineering  repository  software  package.  The  ship 
synthesis  model  is  a  Microsoft  Excel-based  ship  resistance  tool  specifically  implemented 
for  prismatic  planning  hulls.  Optimal  design  space  exploration  was  accomplished  using 
Design  of  Experiments  (DOE)  and  Response  Surface  Methods  (RSM)  from  ship 
synthesis  model  data.  This  was  accomplished  using  the  SAS  JMP  statistical  software 
package.  JMP  provided  visualization  of  the  model  outcomes  and  the  means  to  accomplish 
the  quantitative  trade-off  of  specific  design  variables  in  the  context  of  system  measures  of 
performance  (MOP). 

G.  APPLICATION 

The  methodology  described  in  this  chapter  is  applied  in  the  following  chapters  to 
apply  a  systems  and  mechanical  engineering  approach  to  develop  an  executable  system 
architecture  model  for  the  UV  Sentry  System’s  autonomous  surface  craft.  The  MBSE 
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approach  is  expanded  to  a  model-based  systems  engineering  concept  that  uses  modeling 
in  both  the  conceptual  design  and  architecture  development  process  of  system 
development.  The  architecture  model  and  MCDM  tool  developed  in  this  thesis  provides 
UV  Sentry  stakeholders  with  the  means  to  conduct  and  prioritize  system-level  mission 
and  technical  assessment  studies  in  developing  the  framework  for  the  conceptual  design. 
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II.  UNMANNED  SYSTEMS 


A.  INTRODUCTION 

Unmanned  systems  are  currently  used  in  a  variety  of  military  applications  around 
the  world  to  perfonn  tasks  that  are  dirty,  dull,  and  dangerous  for  soldiers,  sailors,  and 
ainnen  to  perfonn.  They  span  all  domains  including  air,  land,  surface,  and  subsurface 
applications. 

B.  OVERVIEW  OF  CURRENT  STATE 

Unmanned  systems  are  intended  to  provide  significant  reductions  in  manpower 
and  risk  to  personnel  while  providing  persistent  accomplishment  of  mission  tasks.  They 
are  designed  for  a  number  of  security  and  military  applications  with  a  multitude  of 
emerging  capacities  currently  being  developed.  Traditional  roles  for  unmanned  vehicles 
focus  on  the  collection  and  dissemination  of  ISR  information.  Future  unmanned  system 
capabilities  include  autonomy,  targeting,  offensive  and  defensive  fire,  and  multi-mission 
applications. 

Unmanned  vehicles  can  perform  missions  in  areas  deemed  unsafe  or  politically 
sensitive  for  human  operators.  They  can  be  deployed  from  a  variety  of  platforms  and 
maintained  on  station  as  long  as  fuel  and  the  operational  environment  dictate.  UVs  are 
currently  in  use  all  over  the  world,  with  particular  emphasis  on  their  use  in  support  of 
operations  in  Iraq  and  Afghanistan.  Their  use  has  grown  significantly  in  recent  years, 
with  increased  warfighter  demand  expected  in  the  near  future  as  more  emphasis  is  placed 
on  cost-effective  ways  to  provide  safety  and  security. 

C.  PROBLEM  WITH  CURRENT  STATE 

Unmanned  systems  are  typically  designed  and  built  to  perforin  a  single  mission 
and  require  a  robust  support  element  including  numerous  operators  and  maintainers.  The 
personnel  required  to  control,  launch,  recover,  fuel,  and  maintain  unmanned  vehicles 
often  rivals  that  of  manned  systems.  Automation  of  unmanned  system  functions  would 
ease  the  requirement  for  support  personnel  providing  significant  savings  over  traditional 
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UxV  systems.  Along  with  automation,  future  unmanned  systems  must  shorten  the  time  it 
takes  to  refuel  and  return  to  station.  Autonomous  refueling  capability  coupled  with  a 
forward-deployed  refueling  base  pennits  unmanned  vehicles  to  remain  on  station  longer 
by  shortening  refueling  transit  times.  Ultimately,  this  will  further  reduce  cost  by  requiring 
fewer  vehicles  to  perform  a  given  mission  by  reducing  the  frequency  of  on-station  reliefs. 

Communication  and  data  transfer  capabilities  pose  another  significant  issue  in 
UxV  operation  and  development,  particularly  with  USVs.  Current  systems  are  greatly 
hampered  by  the  highly  restrictive  limits  of  line-of-site  (LOS)  and  over-the-horizon 
(OTH)  tactical  links.  Military  and  DoD-commercial  communication  satellites  are 
currently  operating  at  their  maximum  bandwidth  capacity.  Unmanned  system 
communication  requirements  significantly  strain  DoD-dedicated  satellite  assets.  Today’s 
USVs  typically  require  human  operators  to  maintain  LOS  connectivity  with  the  UVs  they 
are  controlling.  The  enormous  bandwidth  and  the  high  rate  of  data  transfer  required  are 
far  too  hefty  for  current  satellite  capabilities.  Having  to  maintain  LOS  connectivity  places 
the  UV  closer  to  the  operator  increasing  the  operator’s  chance  of  hann.  USV  automation 
provides  internal  control  of  system  functions  resulting  in  a  vast  reduction  of  data 
bandwidth  required  for  operation.  This  allows  the  vehicle  to  operate  farther  from  control 
personnel,  placing  the  human  out  of  harm’s  way. 

The  lack  of  system  collaboration  is  another  significant  shortfall  in  the 
development  of  UxV  systems.  There  are  a  number  of  current  UxV  research  and 
development  (R&D)  and  acquisition  programs  in  existence  but  far  less  coordination  and 
capability  sharing  between  organizations  and  their  systems.  This  lack  of  coordination  is  a 
challenge  to  designers  of  future  multi-mission,  multi-domain  UxV  SoS.  Future  UxV 
capabilities  must  incorporate  a  fully  coordinated,  multi-domain,  multi-mission  SoS  to 
achieve  the  full  benefits  of  unmanned  systems.  This  system  of  unmanned  systems  shall 
cover  all  domains  and  function  autonomously  within  its  network-centric  area  of 
operations.  The  systems  components  shall  be  able  to  operate  individually  or  collectively 
to  accomplish  an  assigned  mission.  This  SoS  arrangement  maximizes  the  effectiveness  as 
well  as  the  combat  and  operational  survivability  of  the  system  as  a  whole.  If  an  individual 
unit  is  disabled  or  reassigned,  the  system  autonomously  adjusts  and  assigns  other  assets 
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to  perform  the  re-assigned  unit’s  tasks  in  a  prioritized  order.  An  integrated  network  of 
multiple  unmanned  vehicles  and  external  sensors  can  effectively  span  large  geographical 
areas  greatly  improving  situational  awareness  and  mission  coverage. 

D.  UV  SENTRY 

1.  Overview 

The  UV  Sentry  SoS  is  an  Office  of  Naval  Research  (ONR)  led  initiative 
investigating  the  use  of  unmanned  vehicles  for  force  protection.  The  project  is  aimed  at 
preventing  terrorism  and  piracy  in  the  maritime  domain  using  a  coordinated  assortment  of 
autonomously  controlled  assets  including  air,  surface,  and  subsurface  vehicles.  The 
initiative  leverages  a  consortium  of  DoD,  governmental  department,  industry,  and 
academic  participants  including  warfare  centers,  research  laboratories,  and  the  Naval 
Postgraduate  School.  The  proposed  system  shall,  at  a  minimum,  be  capable  of  searching 
for  and  identifying  potential  threats  from  an  adequate  reaction  distance,  discerning  hostile 
from  non-hostile  entities,  interdicting  hostile  or  non-compliant  units,  and  conducting 
deterrence  and,  if  necessary,  threat  neutralization  actions. 

A  key  near-term  project  goal  is  to  develop  functional  architectures  for  security 
missions  that  support  the  detection  and  identification  of  threats  to  stationary  marine 
platforms.  Figure  7  illustrates  an  example  of  the  UV  Sentry  SoS  used  in  sea  base  defense 
mission.  This  example  includes  mine  warfare  (MIW),  anti-submarine  warfare  (ASW), 
and  surface  warfare  (SUW)  support  missions.  The  stationary  high-value  asset  (HVA) 
protection  mission  was  selected  as  a  good  starting  point  due  to  its  importance,  relevance, 
and  straightforwardness. 
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Figure  7.  UV  Sentry  in  Defense  of  a  Sea  Base.  (From:  Whitcomb  et  al.  2008) 

2.  Need 

Sea  based  assets  are  highly  vulnerable  to  attack  from  a  number  of  adversaries 
with  the  capability  to  inflict  grave  damage.  The  asymmetrical  nature  of  terrorist  attacks 
and  the  large  coverage  areas  to  protect  make  the  protecting  sea  based  assets  particularly 
challenging.  Stationary  HVAs,  such  as  ocean  oil  drilling  platforms,  are  particularly 
vulnerable  and  must  be  protected  from  a  multitude  of  potential  threats  including 
disguised  surface  units,  aerial  attacks,  and  undersea  assaults.  In  addition,  the  relatively 
close  proximity  of  most  stationary  HVA  to  shore  makes  their  protection  an  even  larger 
challenge  due  the  rapid  identification,  interdiction,  and  reaction  times  required. 

Manned  units  spend  countless  hours  patrolling  their  allocated  security  area 
attempting  to  keep  potential  hostile  entities  at  a  safe  distance  from  their  assigned  HVA. 
This  task  requires  manned  operators  to  remain  alert  and  diligent  despite  the  dullness  of 
the  mission.  In  addition,  the  maritime  security  mission  typically  requires  a  large  number 
of  assigned  personnel  to  provide  full  coverage  over  a  large  security  area.  The 
complement  of  manpower  required  to  accomplish  the  mission  depends  on  the  size  of  the 
security  area,  the  importance  of  the  HVA  (including  financially  and  politically),  the 
probability  and  severity  of  potential  attack,  the  nature  of  the  threat,  and  the  availability  of 
protection  force  assets.  In  addition  to  operational  staff,  a  cadre  of  support  personnel  must 
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be  included  for  non-operational  tasks  such  as:  logistics,  maintenance,  training,  and 
habitability.  The  large  number  of  required  personnel  places  huge  financial  burdens  on  the 
U.S.  and  partner  nation  security  forces. 

Protection  of  HVAs  must  be  accomplished  without  placing  personnel,  or  other 
valuable  assets,  in  harm’s  way.  Employment  of  manned  vessels  for  maritime  security 
places  sailors  and  their  ship  in  potential  danger.  The  surreptitious  nature  of  the  threat 
often  compels  security  personnel  to  come  in  close  contact  with  potentially  hostile  entities. 
Coming  within  close  proximity  of  a  capable  and  determined  enemy  places  U.S.  or  partner 
nation  personnel  in  tremendous  danger.  The  loss  of  personnel  or  valuable  national  assets, 
such  as  U.S.  Navy  warships,  is  socially,  politically,  and  financially  deplorable.  COCOMs 
are  committed  to  accomplishing  mission  tasks  while  maintaining  their  assets  as  far  from 
hann  as  possible. 

The  diverse  nature  of  potential  threats  requires  assets  to  search  and  protect  a  large 
geographical  area  in  multiple  physical  domains  (air,  surface,  and  subsurface).  This 
necessitates  the  need  for  a  distributed,  multi-domain,  integrated  SoS  with  elements  that 
operate  in  tandem  to  protect  the  HVA.  Use  of  manned  assets  to  meet  this  need  is  not  only 
costly  but  can  be  dangerous  when  friendly  assets  come  within  close  proximity  of  one 
another.  The  use  of  manned  assets  also  creates  integration  and  communication  challenges 
that  can  easily  result  in  loss  of  situational  awareness  resulting  in  lapses  in  security  and 
potential  harm  to  the  HVA. 

The  UV  Sentry  SoS  offers  the  autonomous,  multi-domain,  distributed,  integrated, 
force-multiplying  effect  required  to  meet  future  HVA  maritime  security  needs.  The 
unmanned  nature  of  the  SoS  maintains  a  high,  persistent  level  of  security  while 
maintaining  safe  distance  for  human  operators  and  valuable  assets.  UV  Sentry  also 
provides  a  cost-effective  alternative  to  using  a  large  number  of  manned  assets. 

3.  Vision/Goal 

The  goal  of  the  UV  Sentry  SoS  is  to  provide  persistent  and  effective  defense  of 
naval  and  maritime  assets.  The  SoS  must  sense,  identify,  interdict,  and  deter  current  and 
projected  threats  to  sea  based  assets.  Figure  8  illustrates  the  UV  Sentry  concept  of 
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operations  in  an  OV-1  view.  The  view  portrays  a  SoS  of  unmanned  heterogeneous 
maritime  vehicles  which  operates  autonomously  and  cooperatively  for  execution  of  many 
different  missions  (Whitcomb  et  al.  2008). 


Mine  Warfare 
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Riverine  Warfare 
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Figure  8.  UV  Sentry  OV-1.  (After:  Whitcomb  et  al.  2008) 


The  UV  Sentry  vision  includes  the  following  capabilities: 

•  Provide  situational  awareness  around  sea-based  assets  at  distances 
sufficient  to  neutralize  detected  threats 

•  Perfonn  ISR  alert  function  and  will,  when  appropriate,  monitor  and 
engage  threats 

•  Operate  and  manage  system  assets  autonomously,  including  autonomous 
refueling/recharging  to  minimize  human  supervision/control/support 

•  Process  data  autonomously  to  provide  a  knowledge  base  for  the 
operational  forces  and  commanders  so  that  they  can  make  informed  decisions 

•  Deploy  non-lethal  and  lethal  weapons  under  human  command  and  control 
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E.  AUTONOMOUS  SURFACE  CRAFT 

1.  Overview 

The  following  section  provides  a  general  overview  of  current  USV  state-of-the- 
art.  This  section  provides  a  baseline  understanding  of  USV  mission  areas,  classes,  craft 
type,  component  areas,  and  technical  challenges. 

2.  Mission  Areas 

The  mission  areas  that  are  relevant  to  the  USV  are:  mine  countermeasures;  anti¬ 
submarine  warfare;  maritime  security;  surface  warfare;  special  operations  forces  support; 
electronic  warfare;  and  maritime  interdiction  operation  support.  These  mission  areas  are 
described  below  and  are  obtained  from  (PEO  LMW  2007). 

a.  Mine  Countermeasures  (MCM) 

“MCM  mission  requirements  are  driven  by  the  Fleet’s  need  to  rapidly 
establish  large,  safe  operating  areas,  transit  routes  (Q-routes)  and  transit  lanes”  (PEO 
LMW  2007).  MCM  mission  areas  can  range  in  size  from  100  to  900  nm  ,  covering 
waters  all  the  way  to  the  shore.  The  objective  of  the  MCM  mission  is  to  enable  safe  Fleet 
Operating  Areas  clear  of  mines. 

The  traditional  MCM  functions  are:  detect;  classify;  localize;  identify;  and 
neutralize.  Each  of  these  functions  is  required  to  confront  the  threat  that  mines  pose 
against  Fleet  platforms.  Additionally,  the  following  MCM  behaviors  encompass  the 
MCM  mission:  reconnaissance;  search;  hunting;  breaching;  clearance  or  clearing 
objective;  sweeping;  jamming;  and  signature. 

USVs,  along  with  UUVs,  are  particularly  well  suited  for  the  “dirty  -  dull  - 
dangerous”  tasks  that  MCM  entails.  They  provide  persistence,  which  permits  significant 
mine  hunting  and  sweeping  coverage  at  lower  cost  by  multiplying  the  effectiveness  of 
supporting  or  dedicated  platfonns.  Additionally,  they  provide  the  potential  for  supporting 
an  MCM  capability  on  platforms  not  traditionally  assigned  a  mine  warfare  mission. 
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b.  Anti-Submarine  Warfare  (ASW) 

“It  is  vitally  important  that  the  U.S.  Navy  be  able  to  achieve  and  maintain 
access  to  all  the  world’s  littorals  at  the  times  and  places  of  its  choosing”  (PEO  LMW 
2007).  There  are  three  major  categories  of  ASW  as  identified  by  Task  Force  ASW: 
“Hold  at  Risk,”  “Maritime  Shield,”  and  “Protected  Passage.”  “Hold  at  Risk”  observes 
submarines  of  interest  as  they  leave  a  port  or  in  transit  through  a  chokepoint.  “Maritime 
Shield”  involves  ensuring  that  a  large  strike  group  is  not  threatened  by  enemy 
submarines.  “Protected  Passage”  entails  establishing  a  safe  path,  free  of  enemy 
submarines,  for  a  large  strike  group. 

USVs  are  able  to  enhance  the  ASW  mission,  specifically,  the  capabilities 
of  “Maritime  Shield”  and  “Protected  Passage.”  Most  of  the  submarine  threats  in  the 
future  will  be  from  numerous  smaller  conventional  vessels  that  are  able  to  operate  in 
shallower  waters  than  U.S.  Navy  submarines  can  operate.  The  objective  is  to  utilize 
USVs  to  “patrol,  detect,  track,  hand  off,  or  engage”  (PEO  LMW  2007)  enemy 
submarines.  The  use  of  USVs  for  ASW  frees  up  manned  platforms  to  focus  on  other 
mission  areas  and  also  enhances  situational  awareness  by  extending  the  sensor  reach  of 
the  unmanned  platfonns. 

c.  Maritime  Security  (MS) 

“MS  consists  of  securing  U.S.  or  allied  domestic  ports,  and  protecting  ship 
and  maritime  infrastructure  (piers,  docks,  anchorages,  warehouses)  at  home  and  abroad 
against  the  spectrum  of  threats  from  conventional  attack  to  special  warfare  [and] 
specifically  target  terrorist  attacks”  (PEO  LMW  2007).  The  key  to  a  successful  MS 
mission  is  the  ability  to  act  on  infonnation  through  good  situational  awareness. 
Consequently,  Intelligence,  Surveillance  and  Reconnaissance  (ISR)  are  of  utmost 
importance  to  the  accomplishment  of  this  mission.  The  MS  mission  is  enhanced  by  the 
unique  capabilities  of  the  USV. 

USVs  are  able  to  function  effectively  away  from  the  home  platfonn  and  in 
shallow  water  to  enhance  sensor  information  while  not  putting  manned  platforms  in 
jeopardy.  Furthermore,  USVs  can  operate  in  areas  that  are  considered  to  be  too 
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hazardous  to  manned  vessels  (both  environmentally  and  militarily).  MS  system  concepts 
include  “sensing,  signal  processing  (for  detection,  classification,  localization,  and 
tracking),  decision  making  (man-in-loop,  semi-autonomous,  or  autonomous),  and 
response”  (PEO  LMW  2007). 

There  are  seven  possible  MS  USV  missions  identified.  These  missions 
include:  strategic  and  tactical  intelligence  collection;  chemical,  biological,  nuclear, 
radiological  and  explosive  detection  and  localization;  coastal  and  harbor  monitoring; 
deployment  of  remote  sensors;  specialized  mapping  and  object  detection  and  localization; 
non-lethal  and  lethal  threat  deterrence;  and  riverine  operations  (e.g.,  civilian  boat  traffic 
monitoring).  The  multi-functionality  of  USVs  and  their  ability  to  be  deployed  from 
various  platfonns  augment  the  ISR  of  U.S.  Forces,  improving  mission  effectiveness, 

d.  Surface  Warfare  (SUW) 

The  SUW  mission  is  very  similar  to  the  MS  mission,  however,  the  SUW 
mission  also  encompasses  the  threats  posed  in  more  open  waters  and  littoral  regions,  and 
the  craft  required  is  more  robust.  The  objective  of  the  USV  SUW  mission  is  to  “provide 
the  ability  to  engage  targets  through  the  use  of  lethal  and/or  non-lethal  weapons  while 
protecting  or  keeping  manned  platforms  out  of  harm’s  way”  (PEO  LMW  2007).  The  key 
capability  for  the  success  of  the  SUW  mission  is  for  the  USV  to  be  configurable  to 
various  payloads  as  well  as  the  ability  to  be  outfitted  with  various  sensors  and  weapons. 

e.  Special  Operations  Forces  (SOF)  Support 

“SOF  units  require  support  for  conducting  missions  involving 
unconventional  warfare,  counter-terrorism,  reconnaissance,  direct  action  and  foreign 
internal  defense,  among  others”  (PEO  LMW  2007).  SOF  is  usually  used  when  the  goal  is 
to  disrupt  by  “hit  and  run”  and  disruption,  instead  of  the  conventional  “force  on  force” 
warfare.  SOF  support  USVs  will  typically  be  required  to  operate  in  coastal  and  riverine 
environments. 

The  main  purposes  for  using  USVs  in  support  of  the  SOF  mission  are  to 
complement  ISR  and  to  provide  transportation  and  logistic  support.  The  inherent 
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versatility  of  the  USV  increases  SOF  mission  effectiveness  and  improves  situational 
awareness  and  SOF  logistics  through  sensor  deployment  and  supply  delivery. 


f.  Electronic  Warfare  (EW) 

The  objective  of  the  EW  mission  is  “to  use  US  Vs  to  provide  a  means  of 
deception,  jamming,  and  warning  of  electronic  attack.  US  Vs  can  provide  a  persistent  and 
effective  capability  with  significant  range,  endurance,  and  capacity  for  large  payloads  and 
power  generation”  (PEO  LMW  2007).  Functions  of  the  EW  mission  are  often  dependent 
on  ISR.  The  USV  EW  mission  encompasses:  creating  false  target  deception;  acting  as  a 
data  repeater  between  large  strike  groups;  and  extending  radar  jamming. 

g.  Maritime  Interdiction  Operations  (MIO)  Support 

“MIO  is  traditionally  defined  as  activities  by  naval  forces  to  diver,  disrupt, 
delay,  or  destroy  the  enemy’s  military  potential  before  it  can  be  used  effectively  against 
friendly  forces”  (PEO  LMW  2007).  MIO  is  inherently  a  manned  mission;  thusly,  the 
USV  MIO  support  augments  the  mission  through  enhancing  situational  awareness.  The 
ideal  use  of  a  USV  for  MIO  support  missions  is  to  provide  ISR  on  a  target  vessel  before  a 
boarding  or  interrogation.  Due  to  the  importance  of  accurate  data  and  the  specialized 
nature  of  this  mission,  emphasis  is  placed  heavily  on  sensors. 

3.  Vehicle  Classes 

The  Navy  Unmanned  Surface  Vehicle  (USV)  Master  Plan  (PEO  LMW  2007) 
organizes  US  Vs  into  four  classes  based  on  analysis  considering  USV  mission 
requirements  and  naval  architecture  characteristics  such  as  stability,  payload,  speed,  and 
endurance.  Class  selection  included  a  weighted  scale  of  USV  critical  attributes  including 
US  Navy  ship  transportability  and  minimization  of  required  accommodation 
modifications.  Although  these  classes  are  near-tenn,  solution-based  USV  alternatives, 
they  are  briefly  described  to  provide  the  reader  with  a  functionality  baseline  and  a 
reference  for  current  design  concerns. 
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a.  X-Class 

The  X-Class  is  small,  special  purpose  craft  intended  to  be  inexpensive  and 
relatively  expendable.  Vessel  length  is  3  meters  or  less  and  expected  to  serve  in  SOF  or 
MIO  support  missions.  They  have  limited  endurance,  payload,  and  seakeeping  abilities 
and  are  not  standardized  for  modularity.  Figure  9  displays  a  few  examples  of  X-class 
vessels. 


Figure  9.  USV  X-Class.  (From:  PEO  LMW  2007) 


b.  Harbor  Class 

The  Flarbor  Class  US  Vs  use  a  7  meter  RIB  as  the  hull  platform  to  conform 
with  current  U.S.  Navy  ship  transportability  and  accommodation  capabilities.  The  craft 
has  moderate  endurance  capability  and  is  expected  to  perform  ISR  and  MS  missions.  This 
class  is  expected  to  retain  the  ability  for  manned  operation.  Figure  10  displays  an 
example  of  a  Harbor  class  vessel. 
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Figure  10.  USV  Harbor  Class.  (From:  PEO  LMW  2007) 


c.  Snorkeler  Class 

The  Snorkeler  Class  USV  is  a  7-meter  semi-submersible  craft,  with  only 
its  snorkel  above  the  surface  during  operation,  providing  a  stable  platform  in  high  sea 
states.  This  craft  is  expected  to  perform  MCM  and  ASW  missions  due  to  its  ability  to  pull 
a  tow  body  and  its  stability  and  endurance  characteristics.  Figure  1 1  displays  an  example 
of  a  Snorkeler  class  craft. 
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Figure  11.  USV  Snorkeler  Class.  (From:  PEO  LMW  2007) 


d.  Fleet  Class 

The  Fleet  Class  USV  is  an  11 -meter  planing  or  semi-planing  craft 
providing  relatively  high  speed,  extended  endurance,  and  moderate  payload  capacity.  It  is 
expected  to  perfonn  MCM,  ASW,  SUW,  or  EW  missions  and  anticipated  to  retain  the 
ability  for  manned  operation.  The  vessel  has  a  modular  design  with  the  ability  to  swap 
mission  modules  in  less  than  24  hours.  Figure  12  displays  an  example  of  a  Fleet  class 
vessel. 
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Figure  12.  USV  Fleet  Class.  (From:  PEO  LMW  2007) 

4.  Craft  Types 


a.  Introduction 


The  Navy  Unmanned  Surface  Vehicle  (USV)  Master  Plan  (PEO  LMW 


2007)  also  classifies  USVs  by  hull  type.  These  potential  alternatives  were  based  on  the 
interface  of  the  vehicle  with  the  sea  surface. 


b.  Semi-submersible  Craft 


The  semi-submersible  craft  operates  with  most  of  its  volume  below  the  sea 


surface  exhibiting  lower  drag  and  platfonn  motion  than  conventional  hull  designs.  This 
results  in  significantly  reduced  drag  allowing  for  a  larger  percentage  of  the  craft’s  power 
to  be  available  for  other  purposes.  The  craft  is  less  affected  by  sea  state,  giving  it  a  larger 
operational  weather  window  and  better  sensor  and  payload  stabilization.  The  platform  is 
very  stable  making  deployment  and  retrieval  of  payloads  easier.  The  craft  has  a  very 
small  radar  cross  section  and  a  low  visual  signature  making  it  very  stealthy.  Craft  speed  is 
limited  to  approximately  25  knots  for  a  7m  craft  and  is  more  costly  than  conventional 


hull  designs  (PEO  LMW  2007). 
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c. 


Conventional  Planing  Hull  Craft 


There  are  a  variety  of  conventional  planing  the  V-Hull,  Modified  V,  and 
M-Hulls.  The  V-hull  is  the  most  common,  providing  relatively  high  speeds  and  a  number 
of  positive  performance  characteristics  such  as  payload  capacity  and  endurance.  Planing 
hulls  are  more  sensitive  to  load  distribution  (especially  when  planing)  and  may  show  less 
towing  efficiency  than  other  craft  types  of  its  size.  At  lower  speeds  (when  not  in  planing 
mode),  these  hulls  perform  similarly  to  normal  full-displacement  craft  and  may  be  less 
stable  especially  in  a  seaway  or  when  at  rest.  At  high  speeds,  the  hull  may  experience  sea 
slamming  especially  in  higher  sea  states  or  confused  seas.  Planing  craft  offer  a  relatively 
high  payload  fraction  and  can  be  of  low  complexity  and  less  expensive  than  many  other 
hull  forms  (PEO  LMW  2007). 

d.  Semi-planing  Hull  Craft 

The  Semi-Planing  hull  exhibits  lower  drag  and  better  moderate  speed 
performance  in  higher  sea  states  than  most  conventional  planing  hulls.  The  craft  typically 
show  less  sensitivity  to  sea  state  providing  a  more  stable  platfonn  for  sensors  or  towing. 
They  can  operate  at  relatively  high  speeds  and  tend  to  be  more  efficient  across  the  entire 
array  of  speeds  than  most  conventional  planing  hulls.  The  hull  form  tends  to  be  more 
slender  with  a  higher  length-to-beam  ratio  and  lower  payload  fraction  than  similarly  sized 
conventional  planing  hulls  (PEO  LMW  2007). 

e.  Hydrofoils 

Hydrofoils  provide  the  lowest  drag  and  best  sea-keeping  of  all  the  hull 
forms  making  them  very  stable,  especially  in  moderate  to  low  sea  states.  They  are 
typically  faster  than  the  other  hull  types  due  to  their  very  low  wetted  surface  area  (when 
at  sufficient  speeds),  often  capable  of  achieving  sustained  speeds  greater  than  40  knots. 
Hydrofoils  are  not  well  suited  for  towing  and  are  typically  more  complex  than  other  hull 
forms  making  them  more  costly  to  design,  test,  build,  and  maintain  (PEO  LMW  2007). 
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f.  Other 

There  are  a  number  of  other  conventional  and  non-conventional  craft  types 
that  are  feasible  for  USV  design.  These  include  pure  (full)  displacement,  Small 
Waterplane  Area  Twin  Hull  (SWATH),  wave  piercing,  and  multi-hulls  (among  others). 
Each  of  these  tends  to  be  appropriate  for  very  specific  capability  needs  and  are  not 
typically  used  in  current  USV  design.  Many  of  these  have  a  tendency  to  cost  more  to 
design,  build,  and  maintain  than  like  craft  and  are  can  be  more  difficult  to  transport  and 
accommodate.  Apart  from  the  full  displacement  craft,  they  are  typically  more  sensitive  to 
weight  changes  and  less  stable  than  other  platforms  making  them  unsuitable  for  most 
towing  and  sensor  operations  (PEO  LMW  2007). 

5.  Component  Areas 

a.  Introduction 

The  below  component  areas  are  essential  to  the  successful  completion  of 

all  USV  missions  and  are  identified  in  (PEO  LMW  2007). 

b.  Hull 

The  hull  is  obviously  the  most  important  component  of  the  USV,  or  of  any 
water  vessel  for  that  matter.  As  discussed  earlier,  there  are  many  different  types  of  hull 
design  that  can  be  used  for  the  USV,  from  conventional  planning  hulls,  to  hydrofoils. 
The  hull  selection  is  dependent  on  the  mission  the  USV  will  be  performing.  The  size  of 
the  hull  is  also  a  function  of  the  mission  type.  Typically,  USV  hull  lengths  vary  from  15 
to  40  feet. 


c.  Ballast 

The  type  of  ballast  used  is  dependent  on  the  selection  of  the  USV  hull  and 
therefore  the  mission  type.  In  general,  ballast  affects  a  vessels  center  of  gravity  and  draft. 
Ballast  is  particularly  important  to  the  semi-submersible  hull  form  because  it  uses  a 
ballasting  mechanism  to  modify  its  position  with  respect  to  the  water  line. 
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d.  Energy 

Auxiliary  power  for  the  electronic  components  aboard  the  USV  is 
typically  generated  by  battery  or  generator  or  a  combination  of  both.  The  auxiliary 
power  must  be  sufficient  enough  to  provide  energy  for  all  electronic  components  on 
board,  such  as,  actuators  for  steering,  sensors,  and  communications. 

e.  Navigation,  Guidance,  and  Control 

Navigation,  guidance,  and  control  are  the  “brains”  of  the  USV.  Without 
these  elements  the  USV  is  simply  a  boat  dead  in  the  water.  The  essential  elements  of 
navigation,  guidance,  and  control  are  accurate  sensors  and  effective  actuators.  The 
sensors  that  are  most  important  to  the  accurate  navigation  and  guidance  of  a  USV  are  the 
Global  Positioning  Satellite  (GPS)  receiver  and  a  radar  system.  The  GPS  receiver  can 
interface  with  a  Digital  Nautical  Chart  (DNC)  that  provides  information  on  permanent 
obstacles  (coastline,  piers,  buoys,  etc.).  The  standard  marine  radar  (Furuno)  is  capable  of 
providing  adequate  data  to  account  for  obstacles  in  motion,  as  well  as  correlating 
information  from  the  DNC  to  enhance  positional  location.  Sensitive  actuators  are 
required  to  control  the  USV’s  steering  and  throttle  based  on  the  environmental  picture 
provided  by  the  sensors.  Control  modes  can  either  be:  “manual,”  where  the  actuators  are 
actually  fully  integrated  into  the  USV;  “drive-by-wire,”  where  the  helm  and  throttle  have 
actuators  attached  to  them;  and,  computer  operation,  where  the  USV  maneuvers  based 
only  on  information  stored  in  onboard  computer.  Additionally,  the  onboard  computer 
will  have  to  take  into  account  the  1972  International  Regulations  for  Preventing 
Collisions  at  Sea  (USCG  1972). 

f  Communications 

The  USV  must  be  able  to  effectively  communicate  information  back  to  the 
host  platfonn  or  possibly  other  US  Vs  through  a  network.  Additionally,  effective 
communications  is  required  to  receive  updated  instructions.  Communication  is  usually 
established  through  line-of-sight  (LOS),  over-the-horizon  (OTH),  through  a  network  of 
USVs,  or  other  relaying  assets.  A  dedicated  and  hardened  communications  suite  is 

required  to  ensure  that  information  can  always  be  relayed  to  and  from  the  USV. 
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Propulsion 


g- 

The  propulsion  system  of  the  USV  must  provide  enough  motive  force  to 
meet  the  demands  of  the  specified  mission.  Propulsion  must  be  adequate  enough  to 
optimize  maneuverability  in  various  sea  states.  Additionally,  propulsion  for  full  payloads 
as  well  as  towing  must  be  taken  into  account.  Propulsion  can  be  supplied  by  either  jet 
drive  or  propellers. 

h.  Masts 

The  mast  of  the  USV  must  be  capable  of  mounting  numerous  sensors  and 
communication  devices.  A  key  characteristic  of  the  USV  mast  is  modularity,  in  the  sense 
that  the  mast  can  be  outfitted  to  meet  the  needs  of  different  missions. 

i.  Auto  Launch  and  Recovery 

USV  auto  launch  and  recovery  requires  both  organic  docking  components 
and  an  off-platform  docking  station.  The  host  platform  will  to  be  outfitted  to 
accommodate  for  this  function. 

6.  Technical  Challenges 

a.  Introduction 

There  are  numerous  technical  challenges  that  the  USV  program  is 

confronted  with.  The  following  technical  challenges  as  presented  in  (PEO  LMW  2007) 
will  be  discussed:  autonomy,  obstacle  and  collision  avoidance;  threat  avoidance; 
automated  target  recognition  (ATR);  autonomous  deployment  and  retrieval  of  untethered 
systems;  and  common  control.  Each  of  these  areas  presents  unique  challenges  that  must 
be  addressed  individually.  USV  technology  will  develop  in  stages  in  an  evolutionary 
process.  Initially,  the  USV  will  be  run  “manually,”  or  in  constant  communication  with 
the  host  platform  where  decisions  are  made  for  the  USV.  The  next  step  is  “semi¬ 
automatic,”  where  the  USV  will  be  in  intermittent  contact  with  the  human  controllers  for 
important  choices.  Finally,  the  USV  will  be  “automatic,”  where  it  will  perfonn  its 
mission  free  from  human  contact,  only  communicating  when  mission  needs  dictate. 


44 


b.  Autonomy 

The  issue  of  autonomy  is  certainly  not  one  that  is  unique  to  the  USV 
mission.  Autonomy  is  the  overarching  ability  that  makes  all  unmanned  vehicles  unique 
in  their  ability  to  act  free  of  human  intervention.  An  autonomous  USV  provides  many 
benefits,  the  two  most  important  being  that  they  enhance  situational  awareness  by 
extending  sensor  reach  as  well  as  make  it  possible  to  reduce  manning  requirements. 
There  are  different  levels  of  autonomy  that  are  associated  with  the  USV,  from 
autonomous  maneuvering  to  autonomous  deployment  of  sensors.  To  overcome  the 
technical  challenges  of  achieving  full  autonomy,  much  research  and  advances  must  be 
made  in  the  fields  of  artificial  intelligence,  algorithms,  and  smart  sensors. 

c.  Obstacle  and  Collision  Avoidance 

There  are  challenges  associated  with  developing  a  USV  that  is  able  to 
avoid  a  number  of  obstacles  and  other  extraneous  objects  that  appear  in  the  environment 
that  degrade  mission  effectiveness.  The  USV  must  have  the  ability  to  steer  clear  of:  the 
shoreline;  other  vessels;  objects  above  the  waterline  (for  inshore  operations);  underwater 
hazards  (rocks,  reefs,  sandbars,  etc.);  floating  debris;  and,  navigation  aids. 

d.  Threat  Avoidance 

Threat  avoidance  is  imperative  to  US  Vs  with  missions  operating  in  or  near 
enemy  waters.  Threats  to  USVs  can  appear  in  numerous  fonns,  including  “ships,  boats, 
aircraft,  active  sensor  systems  (e.  g.,  radar),  and  to  the  extent  possible,  passive  detection 
systems”  (PEO  LMW  2007).  The  challenge  associated  with  threat  avoidance  is  in  finding 
the  balance  between  creating  a  USV  that  can  avoid  threats  and  damage  while  not 
becoming  too  complex  and  expensive  or  degrading  the  original  mission  the  USV  was 
meant  to  perform. 


e.  Automated  Target  Recognition  (ATR) 

ATR  is  a  necessary  element  of  obstacle  and  collision  avoidance. 
Additionally,  ATR  essential  in  successfully  performing  all  USV  missions  (MCM,  MS, 
ASW,  and  SUW).  The  challenge  associated  with  ATR  is  in  the  development  of  a  reliable 
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network  of  on  board  sensors  that  provide  accurate  data  that  can  be  integrated  and 
analyzed  to  create  a  comprehensive  picture  of  the  environment.  Ideally,  the  optimal 
picture  of  the  environment  will  be  through  not  only  numerous  sensors,  but  also  sensors  of 
different  types  (i.e.,  radar,  optical,  infrared,  etc.).  The  key  functions  of  an  ATR  system 
are  its  ability  to  detect  and  identify  an  object  accurately.  Once  sensors  that  are  capable  of 
processing  data  locally  are  developed  and  tested,  the  ATR  challenge  will  be  able  to  be 
confronted  fully. 

f  Autonomous  Deployment  and  Retrieval  of  Untethered  Systems 

Autonomous  deployment  and  retrieval  of  untethered  US  Vs  is  essential 
mainly  to  the  MIO  Support  mission  area.  This  is  an  area  that  requires  much  more 
development.  Technologies  such  as  torpedo  and  missile  launching  platforms  can  be 
studied  and  extensively  modified  to  develop  a  USV  variation  launching  variation. 
Additionally,  as  overall  USV  technology  matures,  more  attention  can  be  given  to  meeting 
the  challenge  of  building  an  affective  deployment  and  retrieval  system. 

g.  Common  Control 

The  envisioned  future  of  autonomous  unmanned  vehicles  involves  systems 
of  systems  operating  in  conjunction  with  one  another  to  fulfill  a  common  mission. 
Common  operational  functionality  between  UxVs  in  a  system  of  systems  sharing 
communication  circuits  and  sensor  networks  stresses  the  need  for  an  open  architecture 
design  to  facilitate  commonality  amongst  all  UxVs.  This  allows  for  modularity  to 
support  multiple  mission  areas,  ease  of  logistics,  life  cycle  cost  savings  and  directed 
technology  efforts.  The  key  to  meeting  this  challenge  “is  in  establishing  standards  for 
interoperability,  communications,  Hull,  Mechanical,  [and]  Electrical  (HM&E)  and 
payload  modularity,  and  Command  Control,  Communications,  and  Computers  (C4) 
architecture. 

F.  SUMMARY 

Chapter  II  provides  a  general  overview  of  current  USV  state-of-the-art  including 
mission  areas,  classes,  craft  type,  component  areas,  and  technical  challenges.  This 
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overview  provides  a  sufficient  knowledge  base  for  understanding  some  basic  concepts 
and  concerns  in  USV  design  and  implementation.  Chapter  III  describes  a  proposed 
process  to  aid  in  the  transfonnation  of  capability  needs  to  conceptual  design  for  the  UV 
Sentry  USV  design  tools  used  to  build  the  MCDM  model. 
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III.  DESIGN  TOOLS 


A.  INTRODUCTION 

The  MBSE  process  is  intended  to  provide  engineers  with  a  structured  method  for 
system  architecture  and  design  development.  The  method  aids  the  iterative  SEP  by 
providing  engineers  and  architects  with  the  framework  and  tools  necessary  to  organize, 
manage,  track,  modify,  and  test  system  design.  This  chapter  describes  the  tools  and 
methods  proposed  for  developing  an  architecture  and  designing  an  autonomous  USV  in 
support  of  a  UV  Sentry  mission.  It  describes  the  elements  and  method  for  the  proposed 
MBSE,  architecture  development  and  decision-making  process  to  aid  in  the 
transformation  of  capability  needs  to  conceptual  design  for  the  UV  Sentry  USV. 

B.  METHOD 

The  SE  process  depends  on  cooperative  innovation  and  iterative  advancements  to 
yield  a  comprehensive  system  that  meets  customer  requirements  needs.  The  key  to 
success  in  the  conceptual  design  lies  in  the  efficient  and  effective  transformation  from 
needs  to  functions  and  from  functions  to  physical  realization.  This  transformation  can  be 
very  problematical  in  a  complex  system  especially  when  using  traditional  engineering 
and  architecture  development  methods.  The  magnitude  of  the  capability  needs,  the 
elaborate  technology  involved,  and  the  intricate  relationships  between  system  elements 
make  designing  an  autonomous  USV  particularly  difficult.  It  is  imperative  that 
stakeholders  maintain  traceability  and  control  through  every  step  of  the  development 
process  and  through  each  iteration  of  the  proposed  design.  It  is  also  critical  to  use  a  series 
of  methods  and  tools  that  enable  stakeholders  to  communicate  ideas,  analyze  tradeoffs, 
and  detennine  and  agree  upon  optimal  designs. 

The  method  uses  several  tools  including  a  ship  synthesis  model,  an  architecture 
model,  and  a  multi-criteria  decision-making  model  to  organize,  construct,  and  transform 
the  system  design.  The  three  models  are  intended  to  be  used  concurrently  throughout  the 
UV  Sentry  SEP  to  continually  improve  design  comprehensiveness  and  fidelity.  The  ship 
synthesis  model  is  the  “physical”  model  used  to  predict  expected  performance 
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characteristics  in  a  simulated  operational  environment.  The  architecture  model  provides 
the  structure  and  organizational  means  to  build  the  various  views  of  the  system 
architecture.  The  MCDM  model  uses  the  static  output  data  from  the  ship  synthesis  model 
to  build  a  dynamic  decision  making  tool  to  be  used  for  concept  exploration  and  trade-off 
analysis.  This  model  enables  stakeholders  to  visualize  the  feasible  design  space 
facilitating  effective  project  communication  and  decision  making.  The  MCDM  tool  uses 
DOE  and  RSM  to  form  a  regression  model  from  ship  synthesis  data  to  build  the 
visualization  and  analysis  tool.  After  making  decisions  based  on  MCDM  analysis,  project 
stakeholders  will  make  the  appropriate  updates  to  the  architecture  model.  Stakeholder 
decisions  and  new  developments,  such  as  constraints  or  technology  maturation,  may  also 
force  changes  to  the  ship  synthesis  data.  When  this  happens,  the  designer  makes  the 
appropriate  changes  and  re-runs  the  model  for  the  next  iteration.  With  every  step  the 
design  development  gets  closer  to  solving  the  design  problem  and  meeting  stakeholder 
capability  needs. 

C.  SHIP  SYNTHESIS  MODEL 

1.  Overview 

The  ship  synthesis  model  is  the  heart  of  this  model-based  design  process.  It 
provides  the  “physical  world”  predictions  that  are  then  combined  to  build  the  conceptual 
design  space.  Properly  capturing  the  design  space  is  essential  to  useful  and  accurate 
concept  exploration.  The  old  adage,  “garbage  in,  garbage  out,”  applies  when  it  comes  to 
exploring  the  design  space.  An  inaccurate  synthesis  model  will  yield  an  unsuccessful 
view  of  the  design  space.  This  skewed  view  could  lead  designers  down  the  wrong  road  in 
the  system  development  process  resulting  in  a  less  than  optimal  design.  The  importance 
of  choosing  the  appropriate  ship  synthesis  model  cannot  be  expressed  enough.  Ship 
design  engineers  need  simple  and  relatively  accurate  estimation  tools  for  predicting  ship 
performance.  There  are  countless  models  to  choose  from,  each  with  their  own  respective 
capabilities  and  limitations.  System  developers  must  work  with  stakeholders  to  ensure 
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system  capability  needs  are  properly  defined  before  choosing  the  synthesis  model,  or 
models,  used.  Designers  must  also  periodically  re-evaluate  their  model(s)  as  iterations  in 
the  SE  process  develop. 

Ship  synthesis  models  typically  involve  a  combination  of  empirical  data, 
theoretical  calculations,  and  experience-driven  rules  of  thumb  to  detennine  physical 
predictions.  Every  synthesis  model  uses  its  own  assortment  of  inputs,  assumptions,  data, 
and  calculations  to  provide  its  user  with  output  information.  Predicted  ship  properties 
such  as  hydrodynamic  resistance  or  displacement  are  projected  to  find  valuable  second 
and  third-order  predictions  like  required  power  or  endurance. 

2.  Model  Selection 

Recent  developments  in  high-speed  craft  have  created  many  different  alternatives 
to  the  traditional  full-displacement  monohull  craft.  Hull  type  selection  is  a  critical  issue  in 
preliminary  ship  design.  Selection  of  hull  form  requires  a  great  deal  of  investigation  and 
analysis  beyond  the  scope  of  this  thesis.  Attributes  such  as  lifecycle  cost,  performance 
parameters  such  as  speed  and  seakeeping,  and  manufacturability  must  be  factored  into  the 
overall  decision  process  when  choosing  a  hull  form.  Planing  monohulls  are  very  popular 
for  use  in  autonomous  surface  vessels  due  to  their  potential  for  high  speeds  compared  to 
traditional  monohull  craft.  For  this  reason,  the  planing  monohull  was  chosen  for  the  ship 
synthesis  portion  of  this  thesis’  model-based  design. 

The  model  chosen  is  an  Excel  model  used  by  naval  architects  at  Naval  Surface 
Warfare  Center  (NSWC)  Carderock’s  Combatant  Craft  Division  (CCD).  The  model  uses 
data  and  calculations  from  Daniel  Savitsky’s  Hydrodynamic  Design  of  Planing  Hulls 
(Savitsky  1964,  71-95).  The  technique,  often  referred  to  as  the  “Savitsky  method,”  is  a 
relatively  simple  but  comprehensive  hydrodynamic  power  prediction  method  based  on 
experiments  conducted  on  prismatic  planning  hulls. 

The  model  is  only  applicable  for  high-speed,  prismatic,  chine  hulled  vessels  in  the 
planning  condition.  At  slow  speeds,  planing-hulled  craft  perfonnance  characteristics 
approach  those  of  traditional  displacement  monohull  vessels.  Non-prismatic  planning 
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hulls  can  be  considered  “prismatic”  in  high-speed  operation  mode.  The  model  equations 
cover  a  variety  of  lift  and  drag  forces  such  as  normal  force,  friction  drag,  and  spray  drag. 

The  model  uses  Savitsky’s  “short  form”  calculation  method  due  to  its  relative 
ease  of  use  and  comprehension.  This  form  assumes  all  relevant  ship  forces  pass  through 
the  center  of  gravity  (LCG)  in  calculating  a  vessel’s  resistance.  Although  this  method  is 
not  as  accurate  as  the  “long  form”  calculation,  it  is  perfectly  acceptable  as  a  perfonnance 
prediction  model,  especially  during  conceptual  design. 

3.  Model  Variables 

The  ship  synthesis  model  is  comprised  of  a  number  of  input  and  output  variables 
applicable  to  designing  relatively  small,  high-speed,  planing  craft.  The  model  inputs 
consist  of  vessel  physical  characteristics,  perfonnance  capabilities,  loading  parameters, 
and  environmental  conditions.  Figure  13  displays  the  ship  synthesis  model  and  associated 
inputs  and  outputs.  The  inputs  (and  units)  are:  vessel  length  (feet),  deadrise  (degrees), 
LCG  (%),  and  velocity  (knots),  percentage  of  cargo  (%),  percentage  of  fuel  (%), 
headwind  speed  (knots),  and  average  wave  height  (feet).  All  inputs  may  be  manually 
typed  or  dialed  in  using  a  visual  slider  via  mouse  (macros  enabled).  Model  outputs 
include  (and  units):  required  shaft  horsepower  (SHP),  maximum  duration  (hrs  and  NM), 
estimated  lightship  (LBS),  and  maximum  cargo  (LBS).  These  values  change 
automatically  when  the  slider  is  moved  or  a  new  value  is  entered  into  a  respective  input 
cell.  The  model  also  includes  a  graph  of  required  power  versus  speed  with  lines  for 
minimum  and  maximum  power  depicted  and  labeled.  The  location  of  each  set  of  input 
values  is  displayed  as  “input  vessel”  on  the  graph.  This  gives  the  user  a  visual  reference 
of  where  an  individual  point  design  lies  on  a  plot  of  required  SHP  vs.  maximum  speed. 


52 


Input 


31  Feet 

Deadrise 

18  Degrees 
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46  Knots 

Avg.  Wave  Height 

2  Feet 

Output 


Figure  13.  Ship  Synthesis  Model. 


4.  Limitations 

Speed  is  an  important  characteristic  of  both  manned  and  unmanned  sentry  craft.  A 
ship’s  ability  to  increase  velocity  over  an  adversaries’  maximum  speed  can  be  the 
difference  between  preventing  an  attack  on  a  high  value  asset  and  allowing  a  threat  to 
enter  an  exclusion  zone.  In  general,  two  principal  forces  limit  speed  improvements  of 
surface  vessels;  aerodynamic  and  hydrodynamic  drag.  Of  these  forces,  hydrodynamic 
drag,  or  the  resistance  of  the  water  on  the  wetted  surface  of  the  hull,  is  the  primary 
hindrance  of  increasing  speed  in  ship  design. 

Reducing  hydrodynamic  drag,  streamlining  the  wetted  surface  of  the  hull  (to 
minimize  turbulence),  and  increasing  the  power-to-weight  ratio  of  the  vessel  are  the  most 
popular  methods  of  increasing  a  ship’s  capability  to  increase  speed.  Unlike  normal 
displacement  hulls,  planing  hulls  use  hydrodynamic  lift  in  addition  to  hydrostatic  lift  or 
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buoyancy.  Hydrodynamic  lift  raises  the  hull,  reducing  the  wetted  area  of  the  hull, 
allowing  the  vessel  to  act  as  a  hydroplane  at  higher  speeds.  At  slow  speeds,  a  planing 
craft  perfonns  like  a  displacement  craft.  As  speed  is  increased,  the  relative  motion 
between  the  hull  and  the  passing  air  and  water  causes  a  hydrodynamic  lift  on  the  bow. 
This  upward  force  results  in  the  aforementioned  reduction  of  wetted  surface  area  and  a 
corresponding  reduction  in  hydrodynamic  drag  thereby  increasing  craft  speed. 

At  planning  speeds,  a  typical  planing  hull  generates  large  amounts  of  waves  and 
spray  adjacent  to  the  hull  when  at  planing  speeds.  The  physical  action  of  the  waves  and 
spray  are  very  difficult  to  predict,  adding  a  great  deal  of  uncertainty  to  any  planing 
model.  In  addition  to  wave  making  uncertainty,  air  resistance  plays  a  larger  role  in  model 
uncertainty  due  to  the  higher  speeds  and  hydrodynamic  forces  involved  with  planing 
craft.  Aerodynamic  hull  factors  have  considerable  influence  on  overall  resistance,  and 
performance,  of  planing  craft.  The  model  addresses  wave  making  and  air  resistance 
uncertainties  by  allowing  the  user  to  enter  headwind  speed  and  average  wave  height. 
Entering  headwind  and  wave  height  infonnation  helps  improve  model  accuracy  but  only 
applies  loose  estimations  of  wave  and  wind  effects  on  ship  performance. 

Appendages  also  typically  add  to  hull  resistance  and  a  corresponding  reduction  of 
speed  and  efficiency.  Bilge  keels,  propellers,  struts,  shafts,  and  sensors  (e.g.  SONAR)  are 
examples  of  appendages  that  add  to  model  uncertainty.  The  model  includes  a  separate 
section  that  allows  the  user  to  add  an  estimated  value  for  combined  vessel  drag.  The 
section  contains  value  cells  for  “new  power  requirements”  and  “new  duration,”  in  hours, 
that  correspond  with  the  added  drag.  This  enables  users  to  account  for  adding  to  or 
increasing  the  size  of  hull  appendages.  The  vessel  drag  function  improves  model  utility 
but  must  be  used  with  caution  as  it  is  based  on  loose  estimates  of  drag  and  assumes  near 
ideal  sea  surface  conditions. 

Calculating  ship  draft  for  planing  hulls  is  difficult  across  the  full  spectrum  of  ship 
speed.  The  draft  of  normal  displacement  craft  is  a  function  of  full  load  displacement, 
length,  beam,  max  section  coefficient,  and  prismatic  coefficient.  A  planing  craft  at  high 
speeds  adds  model  uncertainties,  due  to  hydrodynamic  forces,  to  the  draft  estimation. 
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These  uncertainties  result  in  subsequent  wetted  surface  and  resistance  calculation 
uncertainties  that  detract  from  model  fidelity  and  add  to  model  limitations. 

Elements  such  as  vessel  trim,  shallow  water  bottom  effects,  and  seaway  effects 
typically  effect  craft  performance  and  are  not  accounted  for  in  the  model.  These  effects 
add  a  greater  amount  of  uncertainty  to  the  model  further  limiting  model  fidelity. 
Correction  factors  normally  required  for  non-prismatic  (warped)  hulls  are  also  not 
accounted  for  in  the  model.  The  combined  effects  of  all  of  the  aforementioned 
uncertainty  detract  from  model  accuracy  but  do  not  discount  the  usefulness  of  the  model. 
The  short-fonn  Savitsky  calculation  model  is  a  good  starting  point  to  study  the 
conceptual  design  space.  There  are  models  that  estimate  hull  performance  derived  from 
the  Savitsky  long-form  equations  and  more  accurate  calculations  based  on  better  hull 
form,  appendage,  and  environmental  condition  inputs.  These  models  are  typically  more 
difficult  to  operate  and  understand,  often  clouding  the  truly  important  design  concerns. 
The  designer  must  study  all  available  ship  synthesis  models  and  determine  which  best  fits 
the  particular  type  and  stage  of  system  design. 

D.  ARCHITECTURE  MODEL 

1.  Overview 

The  Vitech  CORE  software  analysis  package  was  used  to  model  the  UV  Sentry 
USV  SoS  architecture  framework.  CORE  is  a  unified  system  architecture  development 
tool  that  provides  the  means  to  integrate  the  model-based  systems  engineering  process, 
DoDAF  structure,  NAERG  tenninology,  and  SoS  architecture  development  process  into 
an  integrated  package.  This  allows  system  architects  to  define,  design,  and  build  a 
complete,  useful,  and  usable  system;  while  lowering  risk  and  engineering  support  costs 
(Vitech).  This  tool  facilitates  architecture  development  and  ensures  system  elements  are 
comprehensive  and  consistent  throughout  the  design  process.  The  system  functions 
within  CORE  are  derived  directly  from  the  Naval  Architecture  Elements  Reference 
Guide  (NAERG)  as  a  predefined  list  of  functions  for  combat,  infrastructure,  and  logistics 
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(Whitcomb).  Consistency  and  traceability  are  effectively  maintained  due  to  CORE’S 
interactive  development,  and  continuous  correlation,  of  operational,  functional,  and 
physical  architectures. 

The  architecture  is  divided  into  two  behavioral  domains:  operational  architecture  and 
system  architecture  (Vitech).  Figure  14  illustrates  the  CORE  architecture  development 
schema  showing  the  system  and  operational  architecture  domains  along  with  their 
respective  elements  and  associated  relationships.  The  operational  architecture  domain 
primarily  consists  of  evaluating  concepts  and  capabilities  while  the  system  architecture 
domain  describes  the  requirements,  functions,  and  components  that  make  up  the  physical 
design  (Vitech). 


Selected  Classes 


Physical 

Element 

Interface 

Element 

>. _ > 

Functional 

Element 

Requirement 

Element 

Figure  14.  CORE  Architecture.  (From:  Vitech  Corporation  2009) 


CORE  is  used  to  capture  and  coordinate  operational,  functional,  and  physical 
models  in  order  to  construct  an  integrated  architecture  (Vitech).  The  three  are  described 
as  follows: 
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•  Operational  models  reflect  how  system  elements  perform  operational 
activities,  interactions  among  the  activities,  the  sequence  of  operation  of 
the  activities,  and  performance  and  timing  associated  with  the  activities 
(Vitech). 

•  Functional  models  reflect  function  decomposition,  data  flow  among 
functions,  the  sequence  of  the  functions,  resource  utilization,  and 
performance  and  timing  associated  with  the  functions  (Vitech). 

•  Physical  models  reflect  platforms,  facilities,  operational  nodes,  systems, 
personnel,  and  interfaces  (Vitech). 

In  the  design  and  development  phases  of  a  program,  systems  development 
activities  often  fall  into  four  activity  domains — requirements,  behavior,  architecture,  and 
Verification  and  Validation  (V&V)  (Vitech).  CORE  concurrently  synchronizes  the 
development  of  all  four  domains  to  ensure  consistency  and  integrity  between  the  domains 
allowing  the  architect  to  locate  and  correct  domain  discrepancies.  Figure  15  shows  the 
four  domains  and  their  interactions  within  the  CORE  construct. 

The  MBSE  process  coupled  with  the  CORE  structure  allows  system  architects 
and  designers  to  effectively  communicate  ideas,  with  common  language,  to  the  various 
stakeholders.  CORE  deliverables  include  DoDAF  “standard”  views  (AV,  OV,  SV,  and 
TVs)  each  representing  a  different  stakeholder  perspective.  Documentation  artifacts  are 
derived  from  the  developed  architecture  and  include  hierarchical  decompositions  and  a 
multitude  of  graphical  displays  to  exhibit  data.  The  output  is  a  fully  developed  and 
integrated  system  architecture  that  contains  specifications,  design,  and  interface 
documentation. 
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Systems  Engineering  with  CORE 


Utilizing  a  layered  approach  to  progressively  clarify  and  elaborate  all  four  domains 
concurrently  ensures  consistency  and  completeness. 


Figure  15.  CORE  Domains.  (From:  Vitech  Corporation  2009) 


2.  Design  Reference  Mission  Example 

a.  Introduction 

A  notional  USV  mission  was  explored  to  demonstrate  how  the  DRM 
process  can  be  used  to  help  build  the  system  architecture.  A  basic  DRM  was  constructed 
for  an  autonomous  USV  in  an  oil  platform  defense  mission.  It  describes  the  background, 
mission,  threats,  environments,  and  a  tailored  Operational  Situation  (OPSIT). 

b.  Background 

A  relatively  tight  margin  exists  between  global  oil  production  capacity  and 
global  consumption.  Stable  collection,  production,  and  distribution  of  oil  and  natural  gas 
are  essential  in  maintaining  the  global  economy.  The  threat  of  terrorist  attack  is  a  very 
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real  threat  to  both  the  oil  and  gas  field  installations  and  to  the  transportation  and 
distribution  systems  connecting  petroleum  fields  to  the  markets.  The  threats  of  attack 
have  resulted  in  higher  market  prices  for  crude  oil  and  natural  gas.  These  threats  place  a 
great  deal  of  emphasis  on  oil  companies  and  national  and  international  authorities  in  oil 
platform  security.  This  vulnerability  makes  offshore  facilities  an  attractive  target  for 
insurgent  organizations  seeking  to  attack  developed  world  economies. 

Unmanned  systems  are  highly  utilized  in  today’s  military  and  are 
increasingly  sought  after  for  future  military  operations.  Combatant  Commanders 
(COCOMs)  are  asking  for  unmanned  vehicles  with  ever-increasing  capabilities  to 
perform  tasks  that  are  considered  dirty,  dull,  or  dangerous  for  manned  platforms.  These 
tasks  include:  surveillance  and  reconnaissance;  signals  intelligence  (SIGINT);  mine 
detection;  force  protection;  homeland  defense;  irregular  warfare;  and  conventional 
campaigns.  Unmanned  systems  have  an  unbounded  potential  to  provide  an  affordable 
force  multiplier  to  U.S.  military  and  law  enforcement. 

The  next  step  in  the  technological  development  of  unmanned  systems  is  in 
the  transformation  from  remotely  operated,  limited  task  unmanned  systems  into 
autonomous,  multi-mission  systems.  In  addition,  greater  efficiencies  and  improved 
interoperability  could  be  achieved  via  an  integrated,  multi-domain,  holistic  approach  to 
unmanned  system  design.  The  UV  Sentry  program  seeks  to  identify  how  unmanned 
systems  can  be  optimized  to  support  a  greater  set  of  mission  areas,  identify  those 
common  areas  of  technology  maturation  that  can  lead  to  perfonnance  improvements  in 
all  domains,  and  identify  the  technology  enablers  needed  to  foster  the  ability  to  conduct 
collaborative  operations  between  multiple  unmanned  systems  in  multiple  domains. 

c.  Mission 

In  general,  autonomous  US  Vs  are  desired  to  perform  missions  that  require 
capabilities  such  as: 

•  Persistent,  wide  area  surveillance,  tracking,  and  interdiction  capability 

•  Target  discernment  in  a  congested  littoral  environment 
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•  ISR  capability  in  potentially  dangerous  areas 

•  Multi-domain  detect-to-engage  capabilities 

•  Automated  data  fusion  into  a  common  operational  picture  (COP) 

•  Autonomous  identification  of  suspect  vessels 

In  a  security  role,  the  Autonomous  US  Vs  must  persistently  search,  detect, 
and  identify  suspect  vessels,  to  a  high  degree  of  confidence,  within  a  large  amount  of 
background  shipping  and  aircraft.  This  mission  is  comprised  of  three  main  phases: 
Surveillance,  Detect  and  Identify,  and  Intercept  and  Engage. 

The  Surveillance  phase  consists  of  using  area  surveillance  and 
autonomous  collection  and  fusion  of  embedded  and  external  sensor  data  to  search  for 
potential  security  hazards.  This  phase  includes  autonomous  task  distribution  between  the 
various  platforms  to  ensure  the  most  efficient  and  effective  combination  of  assets  is 
utilized.  In  addition,  sensor  data  will  be  networked  and  fused  to  maintain  a  continually 
updated  COP.  This  phase  also  includes  automated  launch,  recovery,  and  refueling  of  the 
US  Vs  allowing  the  required  fleet  to  remain  on  station  for  the  appropriate  endurance  to 
perform  the  mission.  The  biggest  challenge  is  in  discerning  suspect  vessels  amongst  a  sea 
of  legitimate  background  marine  traffic. 

The  Detect  and  Identify  phase  detects  contacts  of  interest  (COIs)  for 
further  investigation.  Identification  data  is  used  to  develop  track  histories  and  is  matched 
against  various  onboard  or  external  databases.  Tracks  without  appropriate  data  or 
otherwise  of  interest  are  passed  to  unmanned  surveillance  systems  for  additional  scrutiny. 
Based  on  the  initial  screening,  USV  develops  surveillance  tracks  and  calculates  intercepts 
for  COIs.  If  required,  a  human  can  be  included  in  the  loop  to  approve  or  disapprove 
intercept  plans.  Intercept  and  close-in  surveillance  vessels  are  then  autonomously,  or  by 
human  command,  launched  or  directed  toward  the  point  of  intercept.  Automated  systems 
route  vehicles  to  the  intercept  point  and  establish  close  in  surveillance  of  the  COI.  Input 
from  multiple  sensor  and  data  sources  is  processed  and  fused  to  develop  a  detailed 
understanding  of  the  target.  Based  on  developed  target  data,  a  decision  on  further 
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prosecution  of  the  target  may  direct  the  vessel  to:  continue  surveillance,  end  surveillance, 
direct  manned  intercept,  for  search,  seizure,  or  arrest,  or  direct  engagement  with 
unmanned  system  lethal  or  non-lethal  capabilities,  if  security  environment  demands  and 
ROE  pennit. 

In  the  Intercept  and  Engage  phase,  unmanned  platforms  using  various 
sensors  including  radar,  EO/IR,  and  acoustic,  to  process,  fuse,  and  verily  target 
identification  information  upon  intercept.  The  USV  will  utilize  onboard  and  external 
assets  and  databases  to  support  detection,  tracking,  identification  and  intercept.  The 
vessel  will  intercept  and  track  contacts  of  interests,  autonomously  launching  and 
retrieving  unmanned  vehicles  to  backfill  tracking  vehicles  as  required  due  to  refueling 
considerations.  If  it  cannot  track  the  COI  due  to  speed,  fuel,  or  geographic  limitations,  it 
will  autonomously  notify  external  commands  of  the  targets  location,  course,  speed,  and 
altitude,  if  necessary,  for  intercept  by  other  platforms  or  for  early  warning  of  an  imminent 
attack.  Manned  assets  may  be  used  to  intercept,  board,  inspect,  detain,  or  neutralize  threat 
platforms.  UV  Sentry  will  seamlessly  integrate  with  these  manned  vehicles,  providing 
operators  and  decision  makers  with  information  during  transit  to  complete  the  intercept. 
Wide-area  sensor  platforms  such  as  aerostats,  aircraft,  towers,  or  buoys,  can  provide 
automated  communications  relays. 

In  an  oil  platform  security  mission,  UV  Sentry  assets  typically  maintain  a 
zonal  defense  structure  made  up  of  concentric  area  rings  extending  outward  from  the  oil 
platform  or  field  requiring  protection.  The  outermost  zone,  or  surveillance  zone,  typically 
extends  to  between  6,000  and  8,000  meters  from  the  HVA.  In  this  zone,  the  USV  (and 
support  assets)  autonomously  detect  and  track  all  contacts  that  enter  the  area.  The  next 
zone,  or  warning  zone,  typically  extends  to  between  2,000  and  4,000  meters  from  the 
HVA.  In  the  warning  zone,  the  USV  will  autonomously  warn  all  contacts  they  are  about 
to  enter  the  exclusion  zone  where  they  will  be  engaged.  The  closest  ring,  or  exclusion 
zone,  typically  extends  out  to  approximately  2,000  meters  from  the  HVA  and  marks  the 
threshold  where  the  USV  will  interdict  and  potentially  engage  all  known  threats.  The 
USV  autonomously  allocates  assets  to  specific  tasks,  which  include  surveillance, 
interdiction,  and  warning.  Elevated  sensors  can  be  used  to  provide  radar  coverage  and 
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communication  relays  for  the  Area  of  Responsibility  (AOR).  At  a  minimum,  radar 
coverage  is  designed  to  locate  and  track  all  surface  and  air  tracks  in  the  surveillance  zone. 
Acoustic  sensors  can  be  utilized  to  provide  location  and  tracking  data  for  sub-surface 
contacts  in  the  surveillance  zone.  Radar  and  sonar  coverage  will  be  achieved  by 
integrating  networked  assets  including:  aerostats,  towers,  buoys,  manned  or  unmanned 
aircraft  (with  radar  or  dipping  sonar),  undersea  sensors,  manned  or  unmanned  surface  or 
subsurface  vessels,  etc.  Data  from  these  distributed  multi-domain  sensors  is  automatically 
fused  to  form  a  COP,  which  provides  manned  and  unmanned  operators  with  situational 
awareness  and  the  means  to  allocated  assets  and  make  engagement  decisions.  Automated 
launch,  recovery,  and  sustainment  capabilities  permit  the  craft  to  remain  persistent  in  the 
surveillance  zone.  Sensors  deployed  throughout  the  area  of  interest  detect  COIs  out  to 
just  beyond  the  surveillance  zone.  These  COIs  are  tracked  and  when  unusual  patterns  are 
detected,  such  as  speed  increases,  lack  of  Identification  Friend  or  Foe  (IFF)  or  Automated 
Identification  System  (AIS),  and  when  they  enter  the  surveillance  zone,  an  asset  is 
allocated  to  interdict.  Manned  operators  remain  in  the  loop  to  monitor,  and  when 
required,  approve/disapprove  UV  Sentry  actions.  In  addition,  unmanned  intercept  and 
close-in  surveillance  vehicles  are  launched,  and  later  recovered,  through  UV  Sentry 
automated  launch,  recover  and  sustainment  systems. . . 

d.  Threats 

Threats  to  offshore  facilities  may  come  from  a  multitude  of  sources  in  the 
air,  surface,  or  sub-surface  domains.  Adversaries  intent  on  destroying  or  disrupting  oil 
production  for  political  or  financial  means  are  highly  capable  of  inflicting  major  damage 
to  the  vulnerable  oil  industry.  Marginally  successful  attacks  can  affect  world  oil  prices 
and  destabilize  nations.  A  highly  successful  attack  could  result  in  significant  economic 
and  environmental  damage.  Adversaries  can  include  state-sponsored  militants, 
international  terrorist  organizations,  domestic  terrorists,  or  separatist  organizations.  The 
threats  to  oil  platforms  and  infrastructure  are  asymmetrical  in  nature  requiring  persistent, 
highly  capable  systems  and  processes.  Specific  threats  include: 
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Air  Domain: 

•  Civil  aircraft  (armed  attack  or  suicide  bomber) 

•  Armed  UAV 

•  Cruise  missiles 

Surface  Domain: 

•  Armed  Attack  Boats  (machine  guns,  RPGs) 

•  Suicide  Boats 

•  Armed  US  Vs 

Sub-surface  Domain: 

•  Submarines 

•  Semi-Submersibles 

•  Armed  UUVs 

•  Swimmers 

•  Torpedoes 

The  most  probable  attack  is  likely  to  be  from  an  explosive  device  onboard 
a  small  service  or  pleasure  craft  boat.  This  attack  method  could  prove  particularly 
difficult  to  defend  if  a  Platform  Supply  Vessel  (PSV)  is  used  as  an  attack  vector. 

e.  Environment 

The  offshore  environment  presents  a  difficult  challenge  for  maritime 
forces.  Persistent  surveillance  and  response  area  may  span  thousands  of  square  miles  to 
protect  hundreds  to  thousands  of  dispersed  individual  platforms.  The  traffic  density  of 
legitimate  commercial  traffic  near  oil  field  exclusion  zones  makes  the  environment 
particularly  challenging  to  protect.  The  proximity  to  civilian  and  military  air  traffic 
routes,  commercial  sea  lanes,  fishing  areas,  and  land  make  detection  and  identification  of 
potential  foes  a  huge  challenge.  The  enemy  can  disguise  or  hide  vessels  among  a 
background  of  commercial  and  pleasure  traffic.  The  sheer  number  of  platforms,  large 
area  to  be  protected,  magnitude  of  background  air  and  surface  vessels,  political  and  legal 
considerations,  proximity  to  land,  and  littoral  maritime  conditions  make  the  projected 
operational  environment  (POE)  particularly  challenging  to  security  forces. 
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Environmental  conditions  that  must  be  monitored  and  considered  include: 

•  Temperature 

•  Precipitation 

•  Visibility 

•  Wind 

•  Sea  state 

•  Weather  (including  dust/sand  storms) 

•  Undersea  acoustic  conditions 

•  Radar  propagation  (ducting,  etc.) 

The  political  and  legal  environment  must  be  carefully  considered 

including: 

•  Rules  of  Engagement  (ROE) 

•  Host  nation  sensitivities  and  restrictions 

•  International/maritime  law 

•  Business/financial  considerations 

The  USV  shall  operate  in  both  open  ocean  and  littoral  waters  in  the  wann 
waters  of  the  Gulf  of  Mexico  or  the  Persian  Gulf  to  the  cold  waters  of  Alaska  or  the 
North  Sea.  Water  temperatures  range  from  98  degrees  Fahrenheit  in  the  Gulf  region,  to 
45  degrees  Fahrenheit  in  the  extreme  northern  and  southern  oceans. 

f  Operational  Situation  (OPSIT) 

(1)  Overview.  This  section  presents  a  brief  example  of  an 
OPSIT  used  to  help  identify  capability  needs  for  a  UV  Sentry  USV  operating  in  an  oil 
platform  defense  mission  in  the  fictitious  partner  nation  of  Manitobi.  An  OPSIT  can  be  a 
vague  or  detailed  as  its  author  sees  fit  to  convey  the  idea  and  be  useful  for  analysis.  Some 
sections  are  purposely  incomplete  in  the  interest  of  brevity. 
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(2)  Situation.  The  Manitobi  Liberation  Army  (MLA)  is  a 
growing  terrorist  organization  with  the  knowledge  and  the  means  to  inflict  major  damage 
on  an  oil  platform.  The  organization  is  detennined  to  destroy  or  disrupt  oil  production 
and  distribution  for  the  country  of  Manitobi.  The  government  of  Manitobi  is  a  budding 
democracy  attempting  to  rebuild  the  nation  after  an  intense  civil  war.  The  small  nation¬ 
state  is  in  desperate  need  of  the  profits  it  gains  through  its  international  oil  sales  from  its 
only  operating  oil  platform  M36.  The  platform  is  two  miles  off  the  coast  of  Manitobi  on  a 
recently  discovered  oil  reserve  below  the  ocean  floor.  The  nation  to  the  north  of  Manitobi 
is  a  major  shipping  port  in  the  region.  The  country  to  the  south  is  a  vacation  destination 
harboring  20-30  cruise  ships  each  week  along  with  a  large  number  of  pleasure  craft  for 
fishing  and  sailing.  Many  of  Manitobi’s  people  rely  on  fishing  to  earn  a  living.  The 
combined  effect  of  merchants,  pleasure  craft,  and  fishing  vessels  make  platform  security 
a  major  challenge.  In  addition,  the  platform’s  proximity  to  land  and  other  nations  make 
security  a  time-sensitive  task.  The  U.S.  has  committed  to  defend  M36  but  assets  are 
spread  thinly  throughout  the  world. 

(3)  Mission.  Protect  the  M36  platform  from  a  MLA  attack. 
Use  a  6000m  surveillance  zone,  a  4000m  warning  zone,  and  a  2000m  exclusion  zone. 

(4)  Risk.  Grave  economic,  political,  and  security  setbacks  if 
oil  production  is  disrupted.  Region  destabilization  could  result. 

(5)  Employed  Assets.  The  U.S.  Navy  employed  a  network  of 
sensors  and  US  Vs  to  protect  M3  6.  There  are  eight  US  Vs  each  with  a  docking  station 
attached  to  the  platform.  The  aerial  radar  coverage  is  provided  by  an  aerostat  attached  to 
the  North  corner  of  the  platfonn  deck.  Sonar  coverage  is  provided  by  a  series  of 
disbursed  bottom  tethered  buoys  and  the  USV’s  organic  Sonar  system.  The  U.S.  Navy 
sent  a  crew  of  eight  sailors  to  oversee  the  mission.  The  sailors  monitor  the  USVs  and  can 
interdict,  board,  search,  seize,  and  engage  an  enemy  vessel  using  the  team’s  11 -meter 
manned  vessel  with  a  bow-mounted  .50  cal  machine  gun.  The  operations  center  is  located 
on  the  M3 6  platform  deck  and  requires  one  manned  watch  stander  present  at  all  times. 

(6)  Scenario.  The  Radar  aerostat  detects  three  inbound  surface 
vessels  crossing  into  the  surveillance  zone  on  a  course  toward  the  platform  base  at 
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approximately  30  knots  each.  IFF  and  AIS  sensors  determine  the  vessels  are  not 
identifying  themselves  as  friendly,  or  vetted,  craft.  The  UV  Sentry  system  dispatches 
three  US  Vs  toward  the  inbound  vessels  for  interdiction  and  identification.  As  the  US  Vs 
close  on  the  suspect  vessels,  the  three  vehicles  rapidly  open  the  distance  from  one  another 
in  an  attempt  to  confuse  the  USVs.  UV  Sentry  interdiction  algorithms  recognize  this 
maneuver  and  command  each  USV  to  interdict  a  separate  COI.  The  USVs  meet  the 
inbound  COIs  near  the  warning  zone  and  issue  verbal  warnings  and  close-in  maneuver. . . 

(7)  Summary.  An  OPSIT  is  entirely  dependent  on  the  intended 
mission  and  does  not  have  a  specified  length  or  fonnat.  In  this  case,  the  OPSIT  described 
a  situation,  mission,  risk,  employed  assets,  and  scenario.  The  descriptions  were  included 
provide  an  example  of  an  OPSIT  and  to  show  how  it  can  be  used  to  help  identify  mission 
essential  tasks  and  required  capabilities. 

3.  Mission  Thread 

a.  Overview 

A  thread  is  a  mission-specific  product  that  describes  the  basic  tasks 
required  to  perform  a  mission  function.  Mission  threads  can  be  derived  from  OPSITs  in 
the  DRM  to  help  develop  test  cases  for  specific  system  functions.  The  mission  thread 
provided  was  developed  to  show  a  USV-focused  example  of  how  a  DRM,  OPSITs,  and 
threads  can  aid  in  building  the  initial  (before  iteration)  functional  architecture. 

b.  Thread  Description 

A  USV  patrolling  an  established  protection  perimeter  is  continuously 

collecting,  monitoring,  and  fusing  sensor  data  to  maintain  the  common  operating  picture. 

Among  its  other  sensors,  the  USV  uses  ES  equipment  and  an  IFF/AIS  transponder  to  help 

ID  the  COI  as  friend  or  foe.  The  USV  identifies  a  vessel  as  a  suspect  COI  due  to  its 

course,  speed,  and  radar  emission  frequency.  The  USV  alters  course  and  speed  to 

intercept  the  suspect  vessel.  As  the  COI  alters  course  and  speed,  the  USV  reviews  and 

evaluates  the  ever-changing  situation  and  acts  accordingly.  The  USV  also  communicates 

with  all  required  assets  and  entities  while  navigating  toward  the  suspect  COI.  As  the 

suspect  COI  ignores  warnings  and  enters  the  exclusion  zone,  the  USV  processes  the  COI 
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as  a  target.  After  the  USV  gains  permission  to  engage  the  inbound  COI,  the  USV’s  lethal 
or  non-lethal  assets  are  employed  to  stop  the  suspect  COI. 

c.  Thread  Navy  Tactical  Tasks  (NTAs) 

The  following  tasks  correspond  to  the  thread  description  in  section  3-b  and 
the  example  OPSIT  in  section  2-f. 

•  NTA  6.3.1 .5  Establish  and  Enforce  Protection  Perimeter 

•  NTA  2.2  Perform  Collection  Operations  and  Management 

•  NTA  5.5.4  Conduct  Electronic  Warfare  Support  (ES) 

•  NTA  6. 1 . 1 .3  Positively  Identify  Friendly  Forces 

•  NTA  5.2. 1 . 1  Review  and  Evaluate  Situation 

•  NTA  5.1  Acquire,  Process,  Communicate  Information,  and  Maintain 

Status 

•  NTA  1.2  Navigate  and  Close  Forces 

•  NTA  1.4.7  Enforce  Exclusion  Zone 

•  NTA  3.1  Process  Targets 

•  NTA  3.2  Attack  Targets 

The  tasks  were  mapped  to  their  warfighter  MOEs  in  the  NTTL  and  were 
assigned  applicable  MOPs.  Tables  1,  2,  and  3  summarize  the  tasks,  MOEs,  and  related 
MOPs.  The  MOEs  are  developed  in  warfighting  simulation  and  the  MOPs  are  determined 
from  the  USV  system  component  architecture  model. 
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Tasks 

Measures  of  Effectiveness  [MOE] 

Measures  of  Performance  (MOP) 

Units 

Measures 

NTA  1.2  Navigate  and  Close 
Forces 

Knots 

rate  of  movement. 

Speed 

Percent 

of  maneuver  force 

concentrated  at  decisive 
point  prior  to  detection. 

Speed 

Percent 

of  supporting  force 
concentrated  at  desired 
point  prior  to  detection. 

Speed 

NTA  1.4.7  Enforce  Exclusion 

Zone 

Number 

vessels  located. 

Speed/Endurance/Payload 

Number 

vessels  identified. 

Speed/Endurance/Payload 

Number 

vessels  boarded. 

N/A 

NTA  2.2  Perform  Collection 
Operations  and 

Management 

Percent 

of  targets  accurately 
identified. 

Payload 

Percent 

of  targets  accurately 
located. 

Payload/Endurance 

Percent 

of  PIRs  have  at  least  one 
source  that  yielded 
intelligence  information. 

Payload 

NTA  3.1  Process  Targets 

Percent 

of  desired  results  achieved 
by  expected  conclusion  of  a 
given  phase  or  time  line. 

Payload 

Percent 

of  selected  targets  have 
accurate  coordinates 

available. 

Payload 

Percent 

of  targets  susceptible  to 
non-lethal  kill  allocated  to 
non-lethal  attack  systems. 

Payload 

NTA  3.2  Attack  Targets 

Percent 

of  missions  requested  by 
components  executed. 

Speed/Endurance/Payload 

Percent 

ofhigh  priority  missions 
executed  within  the 
specified  time. 

Speed/Endurance/Payload 

Percent 

of  preplanned  targets 
successfully  attacked 
during  operation. 

Speed/Endurance/Payload 

Table  1 .  MOE  to  MOP  Mapping  (NT A  1 .2  to  NTA  3.2). 
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Tasks 

Measures  of  Effectiveness  (MOE) 

Measures  of  Performance  (MOP) 

Units 

Measures 

NTA  5.1  Acquire,  Process, 
Communicate  Information, 
and  Maintain  Status 

Percent 

of  units  are  in 

communication  with 
commander  throughout 
planning  and  execution. 

Payload 

Hours 

to  process  status 
information  and 

disseminate  to  subordinate 

units. 

Payload 

Percent 

of  available  information 

examined  and  considered 
in  latest  status  report. 

Payload 

NTA  5.2. 1.1  Review  and 

Evaluate  Situation 

Hours 

since  last  review  of 
commander's  plans. 

N/A 

Percent 

of  information  coming  into 
the  headquarters,  of  which 
the  commander  has  cyclic 
management. 

Payload 

NTA  5.5.4  Conduct 
Electronic  Warfare  Support 
fES] 

Time 

to  rapidly  reprogram 
warfighter  sensors  and 
seekers  within  the 
electromagnetic  spectrum. 

Payload 

Time 

from  receipt  of  data  to 
classification  to 

dissemination  of  tactical 

information. 

Payload 

Number 

of  units  with  unresolved 
emitter  ambiguities  in  the 
tactical  picture. 

Payload 

NTA  6. 1.1. 3  Positively 
Identify  Friendly  Forces 

Minutes 

to  confirm  identity  of 
unidentified  target. 

Payload 

Number/Percent 

of  forces  accurately 
identified. 

Payload 

Percent 

of  friendly  casualties  due  to 
friendly  actions. 

Payload 

Table  2.  MOE  to  MOP  Mapping  (NTA  5.1  to  NT  A  6. 1.1. 3). 
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Tasks 

Measures  of  Effectiveness  (MOE) 

Measures  of  Performance  (MOP) 

Units 

Measures 

NTA  6. 3. 1.5  Establish  and 

Enforce  Protection 

Perimeter 

Y/N 

Were  unauthorized 
personnel,  vessel,  or  vehicle 
permitted  inside  the 
minimum  standoff  zone? 

Speed/Endurance/Payload 

Number 

of  minimum  standoff  zone 
penetrations. 

Speed/Endurance/Payload 

Number 

of  minimum  standoff  zone 
penetrations  successfully 
repelled. 

Speed/Endurance/Payload 

Table  3.  MOE  to  MOP  Mapping  (NT A  6.3. 1.5). 


E.  MULTI-CRITERIA  DECISION-MAKING  TOOL 

1.  Overview 

Complex  SoS  like  the  UV  sentry,  consist  of  a  multitude  of  interconnected  systems 
and  components.  The  tight  coupling  of  these  systems  prevents  the  ability  to  optimize  the 
overall  system  by  optimizing  each  individual  subsystem.  This  sets  up  a  complex  blend  of 
system  interrelationships  of  competing  objectives.  As  systems  become  more  complex,  the 
ability  to  optimize  capabilities  becomes  far  more  convoluted  and  difficult  to  improve 
using  traditional  methods.  Multi-criteria  decision-making  methods  and  tools  provide  the 
means  to  optimize  overall  system  performance  by  finding  the  optimal  trade-off  space 
between  several  competing  system  measures.  MCDM  theory  and  application  could  be  a 
thesis  topic  by  itself.  However,  in  this  thesis,  MCDM  is  just  another  tool  in  the  SE 
toolbox  used  for  concept  exploration,  trade-off  analysis,  and  system  design. 

2.  Application 

The  keys  to  effective  concept  exploration  is  both  ensuring  the  entire  design  space 
is  exposed  and  having  the  ability  to  understand  and  communicate  tradeoffs  with 
stakeholders. 

SAS  JMP  statistical  analysis  software  was  used  as  the  MCDM  tool  to  study  the 
UV  Sentry  USV  system  design  space.  JMP  software  provides  the  means  to  utilize  data 
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from  the  ship  synthesis  model  to  construct  an  effective  and  easy  to  use  decision-making 
tool  through  DOE  and  RSM.  JMP  fuses  powerful  software  analysis  capabilities  with 
dynamic  data  visualization  providing  the  user  with  an  interactive  and  flexible  data 
management  and  display  tool. 

3.  Design  of  Experiments  (DOE) 

DOE  is  a  structured  experimental  approach  to  system  or  process  analysis.  The 
approach  is  used  to  quantify  and  examine  multiple  design  parameter  effects  on  an  overall 
process  or  system  design.  The  DOE  is  intended  to  “characterize”  the  system  by 
detennining  which  factors  (variables)  affect  the  response  (outcome).  System 
characterization  is  studied  by  conducting  a  screening  experiment  that  uses  fractional 
factorial  designs.  The  screening  experiment  is  intended  to  estimate  the  magnitude  and 
direction  of  the  factor  effects  (Montgomery  2001).  After  the  screening  test,  the  designer 
should  be  able  to  determine  individual  and  combined  (interactions)  factor  effects  on  the 
response  variable. 

DOE  is  used  to  find  the  minimum  number  of  experiments  that  must  be  conducted 
to  yield  an  accurate  representation  of  the  design  space.  This  allows  the  designer  to 
effectively  and  efficiently  capture  the  critical  process  factors  and  their  corresponding 
effects  on  the  response  while  minimizing  effort  and  required  resources.  DOE  accounts  for 
all  possible  factor  dependencies  from  the  start  ensuring  the  response  data  covers  all 
individual  and  interaction  effects.  This  gives  the  designer  full  situational  awareness  and 
allows  for  the  systematic  removal  of  factors  that  do  not  affect  the  response. 

4.  Response  Surface  Methodology  (RSM) 

RSM  is  a  collection  of  statistical  and  mathematical  techniques  useful  in  the 

development,  improvement,  and  optimization  of  systems  and  processes  (Myers  and 

Montgomery  2002).  This  structured  process  uses  second  order  curve  fits  of  desired  data 

to  generate  a  minimum  collection  of  designs  based  on  groups  of  factors  that  pennit  the 

study  of  an  entire  design  space.  RSM  uses  a  series  of  mathematically  predefined 

orthogonal  point  designs  to  model  the  input-output  relationship,  which  is  then  displayed 

visually  to  represent  the  design  space  for  decision  making  (Katsoufis  2006).  RSM  allows 
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designers  and  stakeholders  to  effectively  view  the  design  space  permitting  concept 
exploration  and  tradeoff  analysis.  RSM  is  efficient,  cost  effective,  and  relatively  simple 
compared  to  traditional  methods. 

There  are  a  number  of  experimental  designs  used  in  RSM  including  the  Central 
Composite  and  Box-Behnken  methods.  Each  design  presents  a  different  experimental 
methodology  and  must  be  selected  based  on  which  best  fits  the  system  or  process  being 
studied.  The  Central  Composite  is  used  to  develop  the  model  due  to  its  inclusion  of  the 
extreme  factor  points  at  the  box  vertices.  Figure  15  shows  a  Central  Composite  design 
cube  with  three  factors.  This  allows  the  designer  to  explore  the  entire  design  space 
including  the  extreme  minimum  and  maximum  factor  areas. 


The  Central  Composite  design  response  surfaces  require  three  levels  for  each 
factor  to  build  the  design  space.  Typically,  threshold  (minimum),  midpoint,  and  goal 
(maximum)  values  are  used  as  the  three  input  factors  levels.  Determining  an  appropriate 
value  range  for  each  factor  is  vital  to  building  a  useful  model.  Designers  should 
understand  that  these  values  detennine  the  magnitude  of  the  design  space  and  must  tailor 
their  choices  to  build  a  precise  model.  A  very  narrow  range  may  result  in  an  exceedingly 
limited  design  space  while  a  range  that  is  too  broad  may  result  in  a  large  fit  error  in  the 
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regression  equation,  severely  weakening  the  fidelity  of  the  model.  Designers  must  choose 
factors  and  parameters  wisely  and  understand  the  consequences  of  their  choices. 

A  second  order  RSM  model  is  used  to  approximate  the  response  once  it  is  realized 
that  the  experiment  is  close  to  the  optimum  response  region  where  a  first  order  model  is 
no  longer  adequate.  The  second  order  model  is  usually  sufficient  for  the  optimum  region, 
as  third  order  and  higher  effects  are  seldom  important.  Figure  17  shows  the  response 
surface  second  order  regression  equation  for  k  (the  total  number)  factors. 

y  =  h0+  £>,*,  +  £  V?  +  ZZ  b,Vj  +  e 

/=1  i=l  i'=l  y'=i'+l 

Figure  17.  Response  Surface  Equation. 

The  bo,  bu,  by  terms  are  constants  determined  from  the  multivariate  regression,  s 
represents  fit  error,  and  the  summations  represent  linear,  quadratic,  and  interaction  terms 
respectively.  This  equation  represents  the  quadratic  response  surface  for  a  given  response 
v. 

F.  SUMMARY 

Chapter  III  describes  the  elements  and  method  for  the  proposed  MBSE, 
architecture  development,  and  decision-making  process  to  aid  in  the  transformation  of 
capability  needs  to  conceptual  design  for  the  UV  Sentry  USV.  Chapter  IV  describes  how 
to  build  the  model  and  provides  a  brief  case  study  to  illustrate  its  usefulness  and 
applications. 


73 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


74 


IV.  MODEL-BASED  ANALYSIS 


A.  INTRODUCTION 

The  model-based  analysis  for  the  UV  Sentry  USV  was  conducted,  as  a  part  of  the 
overall  MBSE  method,  using  SAS  JMP  statistical  software.  JMP  provided  the  means  to 
build  an  effective  MCDM  tool  by  fusing  DOE  and  RSM  techniques  with  predicted 
performance  data  from  the  ship  synthesis  model.  This  method  gives  UV  Sentry 
stakeholders  the  ability  to  explore  the  USV  conceptual  design  space,  perform  tradeoff 
analysis,  and  to  make  informed  design  decisions  in  the  early  stages  of  preliminary  design, 
where  changes  are  cost-effective  and  easy  to  implement. 

B.  CONSTRUCTING  THE  MODEL 

Model  construction  began  with  the  selection  of  the  ship  synthesis  model. 
Choosing  a  suitable  performance  prediction  model  is  critical  to  building  an  accurate 
MCDM  tool.  Model  performance  estimations  are  the  factor  and  response  inputs  to  the 
RSM  equation  and  corresponding  response  surfaces.  If  these  values  are  not  accurate,  the 
RSM  driven  MCDM  tool  will  not  yield  useful  infonnation.  A  prismatic  planning  hull 
model  was  selected  due  to  its  relevance  and  use  in  current  USV  designs.  There  are 
countless  ship  synthesis  models  available  and  appropriate  for  use  in  this  MBSE  process. 
Model  selection  depends  on  many  factors  including  customer  capability  needs,  program 
constraints,  technology  readiness,  and  risk  aversion.  If  the  design  strategy  includes 
exploring  the  feasibility  of  different  hull  forms,  designers  may  choose  to  select  a  number 
of  ship  synthesis  models  to  analyze  and  compare.  The  type  or  number  of  models  selected 
does  not  affect  the  MBSE  process  or  the  construction  of  the  MCDM  tool. 

The  next  step  involved  building  the  design  space.  This  process  began  by  using  the 
DOE  feature  in  JMP  to  design  the  screening  experiment.  A  three-factor  Central 
Composite  design  was  used  to  fully  exploit  the  design  space.  Choosing  the  Central 
Composite  design  resulted  in  the  fifteen  tests  shown  in  column  two  of  Table  4.  Vessel 
length,  speed  (velocity),  and  maximum  duration  (endurance)  were  selected  due  to  their 
relevance  in  USV  design.  Payload  capacity,  displacement,  fuel  weight,  and  power  were 
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chosen  as  the  responses  due  to  their  importance  in  USV  design.  The  ship  synthesis  model 
was  exercised  to  study  the  feasible  high  and  low  limits  in  the  model.  This  step  was  done 
to  ensure  the  parameters  selected  for  each  factor  were  within  the  feasible  design  space. 
This  process  was  necessary  due  to  lack  of  data  on  specific  prismatic  planning  hull  point 
designs  and  the  absence  of  specific  capability  needs  and  system  constraints.  The  goal  of 
this  step  was  to  detennine  actual  values  for  the  threshold,  midpoint,  and  goal  values  of 
each  factor  that  cover  a  potentially  desired  design  space.  The  process  yielded  values  of 
32,  34,  and  36  feet  for  vessel  length  and  24,  29,  and  34  knots  for  ship  speed.  Three 
estimates  for  duration,  200,  400,  and  600  NM,  were  chosen  as  the  threshold,  midpoint, 
and  goal  values  respectively.  Since  maximum  duration  is  an  output  in  the  ship  synthesis 
model,  the  use  of  this  variable  as  a  factor  required  the  use  of  values  as  close  as  possible  to 
experimental  design  specification.  The  input  values  for  payload  (cargo)  and  fuel 
percentages  were  adjusted  in  an  attempt  to  obtain  duration  values  as  close  to  the  200, 
400,  and  600  NM  values  as  possible.  The  actual  model  outputs  were  then  used  as  factor 
values  for  the  table.  The  response  values  from  the  ship  synthesis  model  were  recorded  in 
accordance  with  the  DOE  in  the  JMP  matrix  shown  in  Table  4. 
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Table  4.  JMP  Matrix. 
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JMP  was  used  to  process  the  DOE  data  to  run  the  second-order,  Central 
Composite  RSM  design  model.  JMP’s  “summary  of  fit”  function  was  used  to  check  the 
fitness  of  the  RSM  equation/model. 
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Figure  18.  JMP  Payload  Capacity  Statistical  Summary  of  Fit. 


Figure  18  displays  the  payload  capacity  statistical  summary  of  fit  in  JMP.  The 
payload  response  appears  to  be  a  reasonably  good  fit  with  a  R  value  of  0.91  and  P-value 
of  0.03.  The  relatively  tight  grouping  of  points  along  the  linear  fit  line  confirms  this 
assessment. 

Once  the  equation  is  determined  to  have  a  reasonable  statistical  fit,  the  model  is 
used  to  study  factor  interactions,  analyze  design  space  point  designs,  and  communicate 
design  trade-offs.  The  model  allows  the  user  to  easily  apply  and  manipulate  an  infinite 
number  of  variations  into  the  design  space.  JMP’s  graphical  interface  enables  the  user  to 
visualize  design  variants  freeing  the  designer  from  the  tremendous  amount  of  work  that 
traditionally  goes  into  analyzing  numerous  potential  point  designs.  The  Profiler  function, 
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presented  in  Figure  19,  displays  prediction  traces  for  each  factor.  These  “slices  through 
the  response  surface”  (SAS  2008)  enable  the  user  to  change  one  variable  at  a  time  and  see 
its  effect  on  the  predicted  response.  Evaluation  of  an  individual  factor’s  effect  on  the 
model  can  quickly  and  easily  be  performed  helping  a  stakeholder  decide  the  importance 
and  relevance  of  the  various  factors. 
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Figure  19.  JMP  Prediction  Profiler. 

The  JMP  graphical  interface  can  be  used  to  redefine  the  design  space  adding 
additional  constraints  and  updating  capabilities  as  stakeholders  weigh  in.  Figure  20 
illustrates  the  JMP  Contour  Profiler  feature.  This  is  an  “interactive  contour  profiling 
facility  useful  when  optimizing  response  surfaces  graphically”  (SAS  2008).  The  profiler 
uses  a  2-dimensional  cross  section  of  the  design  space  to  illustrate  how  the  responses 
vary  with  respect  to  the  selected  factors.  In  Figure  20,  duration  is  selected  for  the  y-axis 
and  speed  for  the  x-axis.  The  responses  (payload  capacity,  fuel  weight,  and  power)  are 
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displayed  as  colored  lines  on  the  plot.  The  shaded  regions  represent  infeasible  design 
space  regions  with  respect  to  the  limiting  constraints,  leaving  the  white  space  as  the 
feasible  design  region.  In  this  case,  the  high  limits  of  2,500  pounds  for  payload  capacity, 
4,000  pounds  for  fuel  weight,  and  750  SHP  for  power  were  entered  to  illustrate  the 
shading  of  the  infeasible  region.  The  crosshairs  can  be  adjusted  to  show  specific  point 
values  for  various  locations  within  the  design  space  (under  “Current  X”  in  Figure  20). 
The  contour  profiler  is  a  valuable  tool  to  aid  stakeholders  in  exploring  and 
communicating  potential  designs  within  the  design  team. 
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Figure  20.  JMP  Contour  Profiler. 
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The  mixture  profiler,  in  Figure  21,  shows  “response  contours  of  mixture 
experiment  models  on  a  ternary  plot”  (SAS  2008).  This  feature  allows  the  user  to  display 
and  analyze  the  3 -dimensional  response  surface  when  there  are  three  or  more  factors  in 
the  experiment  are  components  in  a  mixture. 


C.  CASE  STUDY 

1.  Introduction 

The  following  case  study  is  a  brief  example  of  how  the  design  model  can  be  used 
to  analyze  a  specific  design  concern  regarding  payload  capacity.  The  example  assumes 
the  model  is  statistically  fit  and  stakeholders  are  particularly  concerned  with  the  payload 
capacity  of  a  proposed  design  for  an  1 1 -meter  planing  hull  USV. 

2.  Example 

Using  the  DRM  and  mission  thread  data  from  Chapter  III,  the  USV  design  team 
built  the  initial  system  architecture  and  estimated  the  USV  payload  threshold  to  be  3,700 
pounds.  The  team  used  the  MCDM  model  to  test  this  estimate’s  impact  on  the  team’s 
goal  of  meeting  capability  needs  in  a  successful  design.  A  contour  plot  was  used  to  study 
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the  impact  of  speed  and  duration  on  the  payload  estimate,  Figure  22.  The  lines  represent 
different  payload  values,  in  200-pound  increments,  from  2,500  to  5,100  pounds.  The 
shaded  region  represents  the  projected  infeasible  region  below  the  3,700-pound  payload 
threshold.  This  illustrates  where  various  combinations  of  speed  and  duration  fall  in  the 
design  space  with  respect  to  payload.  The  crosshairs  show  that  a  design  with  a  27-knot 
maximum  speed  and  320-NM  maximum  duration  lies  on  the  edge  of  the  feasibility 
region.  If,  for  example,  the  capability  needs  necessitate  the  USV  to  attain  a  speed  of  30 
knots  with  a  400-NM  duration,  the  design  team  will  suspect  this  point  design  to  be 
infeasible  requiring  some  form  of  action  to  take  place.  This  step  is  useful  but  only 
considers  deterministic  values  for  speed  and  duration.  The  uncertainty  involved  with 
predicting  the  achievability  of  these  values  suggests  that  a  probabilistic  model  is  an 
improved  way  to  investigate  the  design  possibilities. 


Figure  22.  JMP  Payload  (case  study)  Contour  Profiler. 
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Next,  the  design  team  uses  the  model  to  run  a  probabilistic  simulation  with 
random  variable  of  speed  and  duration.  The  team  uses  triangular  distributions  for  both 
variables  with  the  lower,  peak,  and  upper  values  shown  in  Figure  23.  These  values  would 
be  selected  from  subject  matter  expert  estimations  based  on  technology  readiness, 
projected  operational  environment,  and  a  number  of  “real-world”  variations.  Since  the 
point  design  uses  an  1 1 -meter  hull  form,  the  length  value  is  fixed  at  33  feet. 
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Figure  23.  JMP  Payload  (case  study)  Simulation  Probability  Functions. 


The  team  ran  the  trial  simulation,  using  the  JMP  default  of  5000  trials,  to  study 
the  effect  of  length  and  speed  variations  on  payload  capacity.  Figure  24  shows  the  JMP 
prediction  profiler  with  the  simulation  results  for  payload  capacity.  The  payload  capacity 
distribution  is  displayed  to  the  far  right  of  the  interaction  curves  with  the  simulation  run 
mean  and  standard  deviation  listed  below  it.  The  simulation  distribution  and  capability 
analysis  are  shown  in  Figure  25.  The  team  included  an  upper  and  lower  specification 
limit  (USL/LSL)  to  represent  their  original  maximum  and  minimum  payload  capacity 
values  that  were  expected  to  meet  predicted  payload  technology  limits  and  system 
capability  needs.  Figure  25  shows  the  5,000-pound  USL  and  3,000-pound  LSL  displayed 
on  the  distribution  histogram  (with  box  plot)  and  includes  the  specification  limit  “sigma” 
standard  deviation  data.  The  long-term  sigma  data  is  presented  to  show  the  chance  that 
the  outcome  may  fall  outside  desired  specification  limits,  not  to  suggest  anything  about 
the  process  capability  for  this  technology  development  study.  This  information  provides 
the  team  with  useful  baseline  data  but  will  be  much  more  valuable  as  the  design  evolves. 
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Figure  24.  JMP  Payload  (case  study)  Simulation  Prediction  Profiler. 
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Figure  25.  JMP  Payload  (case  study)  Simulation  Distributions. 


Finally,  the  design  team  uses  the  JMP  simulation  cumulative  distribution  function 
(CDF)  plot  to  study  the  speed  and  duration  variability  impacts  on  payload  capacity. 
Figure  26  shows  the  CDF  for  payload  capacity  from  the  outcome  of  the  simulation  run. 
This  plot  is  used  to  show  the  probability  of  not  achieving  success  per  a  given  payload 
capacity,  with  respect  to  length,  speed,  and  duration.  Although  the  reverse  CDF  is  more 

useful  and  easier  to  understand,  JMP  does  not  currently  possess  the  capability  to  plot  the 
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inverse  of  curve  in  Figure  26.  Instead,  to  calculate  the  probability  of  achieving  a  given 
payload  capacity,  simply  use  the  inverse  of  the  probability  read  from  the  plot  (i.e., 
subtract  the  value  from  1).  For  example,  by  looking  at  the  plot  and  using  the  inverse 
values,  the  team  determines  the  probability  of  the  USV  achieving  the  desired  speed  and 
duration  at  the  3,000-pound  LSL  value  is  over  90%  while  the  chance  of  accomplishing 
this  at  the  5,000-pound  USL  is  less  than  10%.  As  a  further  example,  if  investigation  leads 
the  design  team  to  alter  their  payload  weight  estimate  to  4,500  pounds.  From  the  CDF 
plot  they  determine  there  is  an  approximately  only  a  15%  chance  that  the  desired  speed 
and  duration  can  be  realized  at  this  payload  capacity  with  the  current  USV  alternative. 
The  team  could  then  decide  that  the  risk  is  too  high  for  this  alternative  and  would  then 
explore  corrective  measures  such  as  investigating  lightweight  payload  component 
alternatives  or  interacting  with  stakeholders  to  see  if  lowering  the  maximum  speed 
requirement,  or  operating  multiple  craft  in  tandem  to  lower  endurance  necessities  would 
be  acceptable  in  meeting  mission  requirements. 

▼  CDF  Plot 


Figure  26.  JMP  Payload  (case  study)  Simulation  CDF  Plot. 

D.  SUMMARY 

The  MCDM  model  described  in  this  chapter  is  a  highly  effective  analysis  and 
communication  tool  for  concept  exploration  and  tradeoff  study.  The  model  is  relatively 
easy  to  build  and  even  easier  to  use.  The  program  uses  a  commercial  off  the  shelf 
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(COTS)  software  that  is  easy  to  find  and  install,  and  is  compatible  with  most  DoD 
computer  systems.  The  most  difficult  step  in  constructing  the  MCDM  tool  is  finding  a 
valid  perfonnance  prediction  model.  The  model,  or  series  of  models,  selected  must 
provide  an  accurate  representation  of  the  physical  behavior  of  the  system  or  component 
being  modeled.  If  the  perfonnance  prediction  model  is  inaccurate,  the  MCDM  model  will 
follow  suit.  In  this  case,  a  planing  hull  model  was  selected  to  predict  USV  perfonnance. 
If  a  different  hull  form  is  selected,  the  design  team  must  find  a  model  that  accurately 
predicts  the  performance  of  the  type  of  hull  being  considered. 

Input  (factor)  and  output  (response)  variable  selection  is  another  critical  step  in 
the  construction  of  the  model.  Variable  selection  is  dependent  upon  their  availability  in 
the  engineering  synthesis  models,  the  critical  parameters  of  the  system  being  designed, 
and  the  uncertainty  of  the  relevant  variables.  In  this  case,  length,  speed,  and  duration 
were  chosen  to  be  the  factors  due  to  their  relevance  to  the  USV  mission.  The  DRM  set 
the  baseline  for  the  USV  CONOPS  and  presented  the  system  context  and  projected 
environment.  From  this,  naval  tasks  were  selected,  from  the  NTTL,  that  formed  mission 
threads  required  to  meet  system  capability  needs.  These  tasks  were  then  mapped  to 
applicable  measures  of  effectiveness  and  to  measures  of  perfonnance  (Tables  1-3).  These 
measures  of  perfonnance — speed,  endurance,  and  payload — were  all  included  in  the 
model  as  either  factors  or  responses.  This  method  guarantees  the  warfighters’  mission 
essential  tasks  and  associated  validation  measures  are  addressed  in  the  model  and  in  the 
design. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  SUMMARY 

The  methods  described  in  this  thesis  are  relatively  straightforward  but  highly 
effective  when  integrated.  The  tools  and  techniques  employed  to  build  the  MCDM  model 
are  not  unique  to  this  thesis.  The  original  concept  proposed  herein  involves  the  unique 
amalgamation  of  these  established  tools  and  techniques  to  construct  an  effective  and 
practical  MCDM  model.  The  first  three  chapters  describe  the  necessary  background  and 
contextual  data  to  set  an  appropriate  knowledge  base  for  the  rest  of  the  work.  The 
fundamental  design  concepts,  scope  and  methodology,  design  tools  and  techniques,  and 
UV  Sentry/USV  background  data  are  described.  Chapter  IV  tied  the  concepts  together  by 
describing  how  to  build  the  model  and  stepping  through  an  example  of  its  usage.  In 
addition,  the  model  was  used  to  study  the  impact  of  stochastic  inputs  and  uncertainty  in  a 
design  example.  Chapter  V  provides  conclusions  for  this  work  and  recommendations  for 
future  study. 

B.  CONCLUSIONS 

The  MCDM  model  and  techniques  described  herein  provide  the  UV  Sentry  team 
with  a  highly  effective  conceptual  design  tool  for  developing  an  USV.  The  thesis  offers 
an  alternative  approach  to  traditional  conceptual  design  based  on  a  capabilities-driven, 
model-based,  SoS  engineering  process  including  explicit  consideration  of  variable 
uncertainty.  This  holistic  approach  to  system  design  keeps  the  design  concepts  and  the 
designer  in  the  feasible  region  with  respect  to  physical,  systematic,  and  capability 
constraints.  The  methodology  is  effective  and  the  thesis  presents  a  tool  set  to  enable 
design,  development,  and  assessment  of  alternative  system  concept  architectures  for  an 
autonomous  USV  in  a  SoS  context.  The  MCDM  model  enables  designers  to  perform  a 
solution  neutral  investigation  of  possible  alternative  physical  architecture  concepts.  This 
ensures  a  consistent  quantitative  evaluation  of  warfighting  capability,  suitability, 
effectiveness,  technology  maturation,  and  risk  before  and  during  a  program  execution. 
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This  effort  is  in  support  of  an  extended  program  to  design  a  system  of  unmanned  systems 
intended  to  provide  the  DoD  with  a  coordinated,  multi-domain,  multi-mission, 
autonomous  security  and  warfighting  asset. 

The  tools  and  techniques  presented  in  this  thesis  are  only  as  good  as  the  system 
designer  that  uses  them.  System  stakeholders  are  still  responsible  for  following  good 
engineering  and  architecture  development  practices  including  proper  problem  definition 
and  effective  analysis  of  alternatives.  System  stakeholders  must  also  promote  adept 
communication  and  thorough  tradeoff  exploration  in  design  development.  This  includes 
true,  unbiased  exploration  of  alternative  system  architectures  capable  of  meeting 
capability  needs.  Preconceived  notions  of  engineering  solutions  may  limit  the  design 
space  resulting  in  a  sub-optimal  system  design. 

This  MCDM  method  described  is  not  limited  to  UV  Sentry,  USVs,  or  SoS.  The 
concepts  and  tools  are  flexible  and  universal.  The  MCDM  model  is  relatively  easy  to 
build,  manipulate,  understand,  and  change.  It  can  be  effectively  utilized  to  aid 
stakeholders  in  making  conceptual  design  decisions  in  the  development  process  of  any 
system,  component,  or  SoS. 

C.  RECOMMENDATIONS 

This  work  is  a  solid  first  step  in  the  quest  for  ultimately  developing  a  UV  Sentry 
SoS.  Some  additional  study  would  advance  the  ability  to  perform  more  extensive  MBSE 
analysis  and  design.  Recommended  areas  for  follow-on  study  include: 

•  Using  an  operational  simulation  of  the  warfighting  capability  to  link  the 
front  end  of  an  executable  architecture  model,  connecting  from  the 
warfighting  simulation  used  to  measure  the  achievement  of  MOE,  traced 
through  the  operational  activity,  operational  task,  function,  requirement, 
and  component  elements  to  the  UxV  design  spaces.  This  would  provide 
quantitative  input  to  stakeholders  from  an  operational  viewpoint. 

•  Modeling  the  requirements  specification  limits  in  the  responses  to 
investigate  robustness  of  MOE  to  MOP.  This  would  provide  the  bounds  to 
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achieve  a  quantitative  technology  risk  assessment  based  on  the  uncertainty 
in  the  technology  development  and  its  impact  on  the  achievement  of  the 
warfighter’s  needs. 

•  Including  cost-effectiveness-risk  trade-off  along  with  the  technology 
impact  assessment  on  the  USV.  The  system  evaluation  should  include 
technology  assessments  with  direct  interface  with  UV  Sentry  technology 
areas,  suitability  evaluation,  effectiveness  evaluation,  cost  analysis,  and 
risk  analysis.  This  would  provide  a  holistic  trade  off  assessment  for  all 
stakeholders  to  use  for  consistent  decision  making. 

•  Extending  the  USV  methodology  to  allow  assessment  of  cross  platform 
interactions  across  all  UxV  in  order  to  perfonn  SoS  level  trade-offs.  The 
overall  goal  of  UV  Sentry  is  to  define  the  optimal  combinations  of  UxV  to 
meet  stakeholder  operational  needs,  from  mission  capabilities  and 
operational  activities.  The  allocation  of  functions  must  be  allowed  across 
the  UxV  platforms  to  detennine  alternative  solutions  in  a  SoS  sense,  and 
not  by  presuming  specific  platform  configurations  of  physical 
components. 
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